L'octidi 28 messidor, an CCXXIII, Martin G. McCormick a écrit : > What replaces the standard sound device?
In short: ALSA. In long: the kernel devices for ALSA are present in /dev/snd/, but applications are not supposed to access them directly, they are supposed to solely rely on the API exposed by the ALSA library, libasound. This library uses that to offer features that we would not like to be implemented in kernel space, including virtual sound devices that do not map to any kernel device. The most useful features of libasound are the plug and dmix plugins: plug converts any format provided by the application to a format supported by the underlying device; dmix allows sharing the same hardware device between several applications without a server; plus, of course, user configuration. If you are using Linux, unless you are using the third-party (IIRC, partially proprietary) OSS drivers (and you would know it), then you are using ALSA and /dev/dsp is almost completely useless. Other Libre operating systems still use the OSS API. > I have written > some experimental programs that play and record sound using > /dev/dsp and they work. Obviously, there is a lot of bad design > in the world that works and I hear the discussion that says that > /dev/dsp is out-dated so what is considered the best way to send > and receive audio in a program? As I said: libasound. Or, of course, any higher-level library that wraps libasound others in a common API. > If there is no /dev/dsp, programs such as mplayer and > the experimental applications I have written will be dead in the > water which is why I am asking these questions now. MPlayer, like all reasonably large current Libre projects, has support or libasound along with other sound API (OSS, of course, SDL, Jack, Sun, win32, etc.). Some program do not. These are mostly crappy old proprietary software, like skype, but as you explain, personal programs without enough manpower are in that case too. For them, various emulation layers exist. The oldest one belongs in the kernel, it exposes /dev/dsp devices, backed by the ALSA drivers. Using it loses most benefits from ALSA: no user configuration, no plugins. The second one is aoss (package alsa-oss): it uses shared library magic to capture access to /dev/dsp and emulates them with libasound. Therefore it has all the features of ALSA, but a few drawbacks, most notably not working with statically-linked binaries. There may also be another similar solution using ptrace(). > The > experimental applications I have written are sound-activated > recording and sound delays. In gcc, ioctl is what one uses to > open /dev/dsp with specific characteristics such as sample rate > and size. I hope what replaces it isn't too indirected. There > are times when it is nice to explain what is happening in one > breath. I know that isn't always possible but it is nice when > you can. The libasound API is more verbose than OSS, but not much more complex. You can have a look at the ALSA device implementation in FFmpeg (libavdevice) for a reasonably simple and self-contained example. Regards, -- Nicolas George -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150716124325.ga2416...@phare.normalesup.org
