Date: Thu, 28 Sep 2006 07:54:01 -0700 From: "Bill Blue" <bblue@netoldies.com> To: "Josh Paetzel" <josh@tcbug.org>, freebsd-stable@freebsd.org Subject: Re: snd_emu10k1 driver Message-ID: <op.tglfob1vzq5pz4@sovaio.netoldies.com> In-Reply-To: <200609270842.03802.josh@tcbug.org> References: <op.tgjcp2b4zq5pz4@sovaio.netoldies.com> <200609270842.03802.josh@tcbug.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Sep 2006 01:42:03 -0700, Josh Paetzel <josh@tcbug.org> wrote:=
> On Wednesday 27 September 2006 11:55, Bill Blue wrote:
>> Hi,
>>
>> Is this driver known to be 100% working? I'm running stable 6.2 p6
>> right now and have this device driver installed (device sound and
>> device snd_emu10k1 compiled into the kernel) for use with a
>> Creative Live! card. Audio outputs work correctly, and the various
>> players will produce audio as expected via the PCM control. Line
>> input works as well. 'mixer' works as does KDE's kmix (they track
>> each other). I've also installed the driver via kldload at boot,
>> but it makes no difference.
>>
>> I'm unable to successfully record audio from the line input of this
>> Creative Live! card. Either using the generic /dev/dsp as the
>> recording source, or individual devices /dev/dsp0.0 and up, dspW0.0
>> and up, or dspr0.4/5. There's just no audio there.
>>
>> For the recording software I've used Krec, ffmpeg, darkice and
>> streamTranscoder (the latter two feeding an icecast server).
>> 'mixer' has its recording device (=3Drec) set to line in, and I'm
>> feeding audio to line in (analog) and spdif in (digital). There's
>> no problem monitoring the 'line in' buss on the outputs, but
>> there's no audio on the record output device.
>>
>> dmesg shows the driver being installed, and cat /dev/sndstat shows
>> it is active on pcm0. If I cat /dev/sndstat with a higher
>> verbosity (set with sysctrl) it shows that the record devices
>> should be dsp0.4 and dsp0.5, line and mic in respectively. The man
>> page for snd_emu10k1 says the recording devices should be dspr0.4
>> and dspr0.5 but only if they're driving a codec directly -- I'm not
>> sure what that means exactly.
>>
>> There's no sound daemons like esound or artsd running during these
>> tests. The ports being tested as an input device seem to open
>> correctly and show up as read devices in fstat.
>>
>> I've also tried the snd_emu10kx driver to no avail.
>>
>> Has anyone had experience using the Live! sound card and these
>> drivers? And if so, is recording correctly supported?
>>
>> I have other sound cards available, but none of them seem to have
>> driver support in FreeBSD. One is a Delta (Midiman) 410 with an
>> ICE1712 chip, and the other is a Turtle Beach TB400 (not a Santa
>> Cruz) with Vortex AU8830A2 chip. Both cards have analog and
>> digital ins and outs.
>>
>> Anyone with insight on any of this?
>>
>> --Bill
>
> I thought I'd try this out since I have a SB Live! 5.1, use the
> snd_emu10k1 driver and don't run artsd or esound but when I start
> krec the record button is greyed out! Using ffmpeg and the /dev/dsp
> device I was able to record just fine from the mic port on the card.
>
> I'm running 6.1-R-p6
Here's my various outputs:
Sep 20 19:18:12 v2 kernel: pcm0: <Creative EMU10K1> port 0xd000-0xd01f i=
rq 21 at device 2.0 on pci4
Sep 20 19:18:12 v2 kernel: pcm0: <TriTech TR28023 AC97 Codec>
FreeBSD v2.netoldies.com 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #1: Sun S=
ep 17 15:37:40 PDT 2006 root@v2.netoldies.com:/usr/obj/usr/src/sys/V=
2KERNEL i386
FreeBSD Audio Driver (newpcm)
Installed devices:
pcm0: <Creative EMU10K1> at io 0xd000 irq 21 kld snd_emu10k1 (4p/2r/4v c=
hannels duplex default)
pcm0@pci4:2:0: class=3D0x040100 card=3D0x00211102 chip=3D0x00021102 rev=
=3D0x04 hdr=3D0x00
vendor =3D 'Creative Labs'
device =3D 'EMU10000 Sound Blaster Live! (Also Live! 5.1) - OEM f=
rom DELL - CT4780'
class =3D multimedia
subclass =3D audio
emujoy0@pci4:2:1: class=3D0x098000 card=3D0x00201102 chip=3D0x7002=
1102 rev=3D0x01 hdr=3D0x00
vendor =3D 'Creative Labs'
device =3D 'EMU10000 Game Port'
class =3D input device
I have found the problem, which turned out to be mostly that of (lack of=
good) documentation and user interpretation. The mixer man page doesn'=
t really talk at all about signal routing, and the kmix man page says al=
most nothing useful, with examples that address only one card type. snd=
_emu10k1's man page says less than all the others combined.
'mixer -?' gives a list of input devices and record devices:
devices: vol, pcm, speaker, line, mic, cd, rec, igain, line1, phin, ph=
out, video
rec devices: vol, line, mic, cd, line1, phin, phout, video
and 'mixer' gives a list of all devices and slider settings with no rega=
rd to what they do or how they interrelate, and the default record devic=
e (=3Drec).
At least in this driver, the devices pcm, line, mic, cd, line1, phin, ph=
out, and video, seem to be strictly inputs -- a mix of internal system a=
nd external jack inputs. pcm is an input from software media players, l=
ine and mic are external inputs, cd and possibly line1 are 4 pin connect=
ors on the card itself, but I don't know the role of phin, phout and vid=
eo. vol is master playback volume. The spdif input on the Live! card d=
oesn't seem to be supported.
The rec devices are mostly self explanatory, except for two issues. Fir=
st, on this driver there's only a single device selectable for record at=
one time (i.e. no record mixer). That devices record level is unaffect=
ed by its playback slider level. Second, the selected device's record l=
evel is controlled by the rec slider (only), and is independent of all o=
ther levels UNLESS the selected record device is vol. In this case rec =
controls the record level of the signal mix being fed to the system mast=
er volume slider.
Kmix's layout really confuses the roles of the various signals, and even=
calls the rec device RecMon which implies a different functionality. X=
mixer lays all devices out on the same pane with no notion of routing.
So, like in the Windows drivers, I was selecting the correct device unaw=
are that whatever device I selected was being record-level-controlled by=
rec. Bah.
Anyway, after figuring this out everything works fine with the driver it=
self. Hopefully, the explanation above will help out someone else about=
to make the same stupid mistake. Perhaps future versions of UI's can b=
e laid out in such a way that you can just look at them and understand t=
he routing.
Thanks to those who responded.
--Bill
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.tglfob1vzq5pz4>