its in the code, duh .. what more grok do you need? -- ; Jay Vaughan

On Wed, 2006-03-01 at 15:15 -0500, Lee Revell wrote: Seriously, I do think a valid point has been raised (though the problem is not nearly as bad as "ALSA is an undocumented maze"). Besides my previous statement about use of front, rear, default PCMs, what other details might an ALSA mini HOWTO for end users cover? Please don't mention .asoundrc (should be completely invisible to the end user if everything is working right) or alsa-lib API (developer stuff is already well documented). Lee

Lee Revell <rlrevell(a)joe-job.com> writes: It is actually more like a hoax. To wit: I have a builtin sound card into my laptop without any spdif/iec958 folderol. Now I plug in an IEC958 adapter into USB (which counts as a soundcard of its own). What happens now if I do aplay -D spdif something.wav ? Most certainly not the soundcard with the S/PDIF output gets used. Instead some nonsense happens. I have found no way whatsoever to get this card to output anything except by using Ubuntu's Sound preference setting to make the ridiculous S/PDIF only sound gadget the default sound device. Only then will I ever get aplay (which in contrast to alsamixer does not have something like a -c 1 option to specify card 1) to use the SPDIF gadget. But I don't want to use the gadget for all of my output. And I have been unable to find any man page or info or web page accessible by Google that would tell me how to do this. It is rather silly. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

There are several issues at different points: * alsaconf has done a really great job in the past, but meanwhile I see the need for a replacement which can handle more than one card, support USB (and in the future firewire) devices, can read an existing configuration, set a certain device as the default device and so on. Based on such a new script, we then could build even GUI configuration frontends (Qt, Gtk, KDE, you name it) * ALSA aware applications need to offer the possibility to choose the card to use. Many users have more than one device these days, a cheap AC '97 one and a cool 7.1 USB device. When playing a video file, there should be a possibility to tell the player which device to use. On tour with my notebook I prefer to output audio of a DVD mixed as stereo on my internal speakers while at home or at a friend's I'll better use my USB device * Applications should remember the last used device (not to mention soundservers here) so the user gets a straightforward experience ("I once set it up and since then it simply works(TM)") * Users need a simple GUI to set the default (=most often used) device, maybe renaming the cards, configuring special options easily (asoundrc resp. special options in modules.conf like card ordering) * ALSA runs a driver based on the chipset found. Unfortunately, and I mainly have those AC '97 chips in mind, these have a huge set of features a user never needs or even worse which are not available on the chassis. But ALSA cannot know that because it only knows the chip. Furthermore ALSA builds a generic mixer interface for the chip. That's a really cool piece of software, but have you ever tried on a notebook with an AC '97 chipset to set up your card for VOIP properly? An average user will be lost. Therefore I had the idea to put an additional layer between ALSA and the mixer interface so users can contribute mixer descriptions for wide spread cards. If such an desription doesn't exist, ALSA could still fall back to the generic mixer interface Just my two Cents. Best regards ce

is there a backend script available, distro independant? I'd like to look at it simply for my personal interest. Does it have a name? Indeed it is. OTOH xmms is a very positive example. Best regards ce

what about indexing the cards in modules.conf? Works great for me even when hotplugging USB devices (and I use 5 of them ;-) Best regards ce

true. What does it do technically spoken? Creates a user asoundrc with a default device? Best regards ce

On Thu, 2006-03-02 at 00:09 +0100, David Kastrup wrote: now that's what i call a sick joke. if only i had more time, i'd be writing CoreAudio for linux right this very second. --p

On Wed, 2006-03-01 at 17:28 -0500, Lee Revell wrote: no, it would provide names like MOTU 828 mkII channel 1+2 RME HDSP (#1) Builtin Audio to the user. it would also fix a myriad of other problems in ALSA, such as its reliance on interrupts that occur at regular sample-based intervals, its presentation of a multiplicity of programming models, and its lack of reasonable way to present itself to ordinary users. --p

i don't need to - they are fully documented by Apple in its description of the HAL for audio devices. Rather than rely on the interrupts as absolute indicators of time, you use them to feed a DLL. Then you use the DLL in conjunction with a monotonic clock source (e.g. a cycle timer or a reliable equivalent on certain AMD systems), and you can estimate position in the h/w buffers to way better than single sample accuracy at all times. more importantly, you can do this no matter what the basis for the interrupt frequency is, so you get a single HAL model that works equally well for PCI, USB and ieee1394 devices. Apple don't agree with you, and neither do Steinberg or Microsoft (the modern, reformed post-MME Microsoft, anyway). They each offer a single programming model at the HAL level, and remarkably, its the same programming model in every case. I don't see forums for those platforms complaining that its a problem. Only unix programmers who go about insisting that "everything should be a file, all i/o should be open/read/write/close/ioctl" seem to have a problem with it, yet curiously have no problem with the fact that you don't do video in that way at all. i meant more generally. ALSA is so full of configuration options that will be used by almost no-one that its incredibly confusing for almost everyone. i wrote years ago on alsa-devel about the paper from the guy at SGI who was involved in their video API design and ended up being a little disappointed. his reason? they went to so effort to handle all the corner cases that the core use case ("dump pixels into this part of the framebuffer") was remarkably complex to do. ALSA strikes me as much the same way, at every level, from the kernel API, to libasound, to user space utilities. one could argue, as Lee has done, that people (programmers, users) should be using higher level APIs and leave the complexity behind, but somebody or something has to deal with it at some point in order to get sound in or out of the machine. --p

Jussi Laako <jussi.laako(a)pp.inet.fi> writes: No, that's not what we are arguing, at least how I understood it. The topic was not complexity but accessibility. If it is impossible to find explanations, stuff is hard to do. A well-documented crummy interface can be easier to work with than an under-documented well-designed one. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

"Richard Spindler" <richard.spindler(a)gmail.com> writes: Few people would glimpse at header files in order to figure out the command line arguments to "aplay". -- David Kastrup, Kriemhildstr. 15, 44793 Bochum

On Wed, 2006-03-01 at 21:40 -0500, Paul Davis wrote: How would you solve this? Make people who insist on a read()/write() interface go through the OSS emulation layer? Would you remove everything but the mmap() interface? The callback interface? Lee

On Wed, 2006-01-03 at 17:18 -0500, Paul Davis wrote: 1) Eliminate alsa-lib 2) Put jackd in kernel 3) Profit! -DR-

On Thu, 2006-03-02 at 00:09 +0100, David Kastrup wrote: I think this is just a bug. Can you repost this report to alsa-user at lists.sourceforge.net or report it in the ALSA bug tracker? https://bugtrack.alsa-project.org/alsa-bug/login_select_proj_page.php?ref=b… Lee

On Thu, 2006-03-02 at 00:25 +0100, David Kastrup wrote: What about -D hw:1 or -D plughw:1? USB audio devices are weird, it's much harder to determine sane defaults than for PCI devices. Lee

On Wed, 2006-03-01 at 22:32 +0100, David Kastrup wrote: That can't ever work because we don't have enough information about all the supported devices to definitively say device $FOO has SPDIF and device $BAR doesn't. Lots of devices look like they have SPDIF to the driver but it's not wired up to anything. Etc. Solving this problem in the way you suggest would require the ALSA developers having all the details about the hardware that the people who write the Windows drivers do. This is not going to happen anytime soon. Lee

On Wed, 2006-03-01 at 23:07 +0100, David Kastrup wrote: Well the Windows docs don't say what a "Wave device" is but people seem to figure that out. PCM is merely a more technical term for what is called "Wave" on windows. What does MacOS call it? Lee

On Wed, 2006-03-01 at 23:07 +0100, David Kastrup wrote: If someone wants to set up an "ALSA mini HOWTO wiki" I'll start the content, by adding the info from this thread. But it can't stay a Wiki because those fill up with misinformation or extraneous information eventually - when it's done we'll publish it as a static HOWTO. Lee

On Wed, 2006-03-01 at 23:21 +0100, David Kastrup wrote: Well, tough shit, because all I have time for is a mini HOWTO, unless you're offering to pay me. Lee

On Wed, 2006-03-01 at 23:40 +0100, David Kastrup wrote: Well, I didn't develop ALSA originally, I've just contributed patches to a few drivers. You'd have to ask the authors on alsa-devel about the lack of better examples in the man pages. Most users will never have to bother with this stuff - the app will just give them a dialog that lets them select a sound device. Also, a lot of CLI apps don't accept ALSA devices in the standard syntax because they reserve : for something else (mplayer comes to mind). Lee

a condensation would be really cool. What about http://alsa.opensrc.org ? Best regards ce

Alfons Adriaensen wrote: If you don't like the current documentation, you are welcome to improve it. Just update the wiki. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.