| |||||||||||||
LPC: Linux audio: it's a messLPC: Linux audio: it's a messPosted Sep 20, 2008 13:16 UTC (Sat) by cortana (subscriber, #24596)In reply to: LPC: Linux audio: it's a mess by smorovic Parent article: LPC: Linux audio: it's a mess
The problem with the alsa-provided /dev/dsp is that programs using it don't get software mixing. So such programs will block off all sound for all other programs on the system; or if sound is already playing, they will fail to play sound themselves.
(Log in to post comments)
LPC: Linux audio: it's a mess Posted Sep 20, 2008 20:43 UTC (Sat) by adamgundy (subscriber, #5418) [Link]
the 'cuse' OSS emulation smorivic linked to is an attempt to fix that disastrous mess..
as you said, if you use ALSA's built in OSS emulation, that's a kernel module, and competes with any other ALSA source for the sound device. most newer sound devices (consumer, at least) only support a single playback channel, and expect software mixing to be done... but dmix (ALSA's mixer) is a userspace mixer using the ALSA drivers, which means the ALSA-OSS kernel module can't use it, hence blocking audio (it also means no mixing is available for OSS users, so only one at a time can use OSS)
CUSE is a way of providing /dev/dsp and friends for OSS emulation from userspace, so of course a userspace OSS emulator can use dmix, pulseaudio, or whatever and play nicely with other apps.
CUSE lets a userspace program catch the full range of operations on the /dev/dsp device, so it can be a full emulation, unlike tools like aoss which hack into glibc's open calls and try to detect opens of /dev/dsp and do the emulation there (they can't catch everything, so some stuff works with aoss, other stuff doesn't).
LPC: Linux audio: it's a mess Posted Sep 21, 2008 8:27 UTC (Sun) by mlankhorst (subscriber, #52260) [Link]
Alsa already had oss support in the form of aoss, which hooks all ioctl's
and read/writes to /dev/dsp, so the only thing new is that this form uses CUSE instead of hooking function calls with preloading.
LPC: Linux audio: it's a mess Posted Sep 21, 2008 22:20 UTC (Sun) by adamgundy (subscriber, #5418) [Link]
the point is that aoss (and other variants) can't catch *everything* (mmap, etc), but I believe CUSE is intended to allow a user space process to catch all the same stuff as the kernel mode emulation can.
also, aoss is a pain for most users, because they have to start the program they want to 'emulate' under aoss, typically from a command line. CUSE just sits there as a daemon, waiting for any process to attempt to use /dev/dsp.
LPC: Linux audio: it's a mess Posted Sep 21, 2008 23:03 UTC (Sun) by mezcalero (subscriber, #45103) [Link]
PA has "padsp" which is similar to "aoss".
However, this kind of virtualization is always imperfect, won't work for more complex applications that use mmap, or make assumptions about timing and hardware that a software sound server cannot meet.
Doing emulation with LD_PRELOAD is always hacky, incomplete, and can only be a temporary solution that only works in very specific cases.
Lennart
LPC: Linux audio: it's a mess Posted Sep 21, 2008 23:07 UTC (Sun) by mezcalero (subscriber, #45103) [Link]
CUSE is certainly a good thing. But it won't solve our problems entirely. OSS allows clients to read the playback pointer of the hw which apps use for synchronization. Now, in sound servers (and even on stuff like USB) we have a hard time to support this, since we usually have an extra latency "behind" the playback buffer. So, either the timing the application gets will be way off what actually is true -- or we will have to minimize that aforementioned extra latency at the cost of high CPU load.
So again. Regardless which approach we use: 100% compat won't happen.
LD_PRELOAD is good for some things, CUSE for others. But in the end, 100% OSS compat that works for everyone and always will stay a dream.
OSS as and API needs to go away.
Lennart
|
|||||||||||||