OSS vs ALSA API (was Re: Is it time for remove (crap) ALSA from kernel tree ?)
Hi! > >Today both OSS and ALSA teams have to spend significant > >amounts of time in emulating the "alien" APIs. Making > >OSS and ALSA to co-exist will require some work in both > >sides but that should be nothing when compared to the > >effort required for emulation. > ... > In Linux we typically do not do two APIs and codebases > for the same purpose. If we do, like sys_mmap and > sys_mmap2, it's an older legacy interface that never > changes, that we are moving people AWAY from, and a > newer interface. > > I see no reason to change from the path at which > upstream has arrived: OSS is a legacy API that's frozen > in time, and ALSA provides the new stuff. While I agree that ALSA is better than OSS... I don't actually think ALSA kernel<>user api is... at least for my purposes. I'm still using OSS emulation, because I could not get alsa proper to work... and the advanced stuff just does not work in emulation. In OSS days, if you wanted to test kernel sound driver, you did: mknod /dev/dsp cat /bin/bash > /dev/dsp. With alsa+oss emulation, you need mknod /dev/mixer install aumix aumix mknod /dev/dsp cat /bin/bash > /dev/dsp. With alsa proper, it is install alsalib create about 5 device nodes install alsautils maybe do some config? aplay some.wav ..provided you have .wav near you. I'm not sure if it is possible to produce sounds using normal shell scripting? (w/o alsautils)? I can even test kernel graphics drivers by cat /bin/bash > /dev/fb0... it would be nice to have equivalent for audio... OSS API seems to be the equivalent these days, but please don't deprecate it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Hi! > > > > Soft mixing is actually the biggest issue because if you had > > generalized soft-mixing in the kernel-visible audio ports[1] you would > > win two things: > > > > - programs could use the OSS API without interfering with the ALSA one > > or which each other > > This works with aoss. > > If people often run into this problem it might make sense to deprecate > the in-kernel OSS emulation and point people to the userspace emulation > instead? Without in-kernel OSS emulation, it is very hard to verify if kernel sound support works properly. OSS could been driven from shell for testing, and I believe that's still important feature to keep. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Sat, Jul 07, 2007 at 02:41:05AM +, William Pitcock wrote: > The most fucked up thing that I can think of about the current state of > affairs in ALSA is dmix. Every other UNIX sound system like ALSA does it's > software mixing in kernel space. The applications never even know about > it. It's not only until recently (2005-2006 or so) that ALSA came close to > this, but there are still problems. Many cards need workarounds to make > dmix work because of the way it works, and the way that ALSA buffers data > around. I have to agree. I am not an audio programmer, just a user; but the bottom line is simply: It is WAY to hard to get things working (if at all possible). At one point I tried to get sound from xmms and ut2004 at the same time (on my new machine). I was ASTONISHED that it didn't Just-Work! After trying many complex things-- I gave up and put my old soundblaster Live! in the new PC - because that card has hardware support for this. Now I was lucky to HAVE that other soundcard, but what about all those other users out there who just buy a new PC, with a sound chip on the motherboard and then, being simple, ordinairy users, have to face this ALSA configuration hell to do something as simple as having two audio applications play sound at the same time? > For the non-technically inclined, ALSA only keeps two fragments for > input/output data each. This is horribly unusable because most soundcard > fragments are only 1KB, so applications have to adopt ringbuffers to pass > data to ALSA. If you're doing video, this leads to possible timing issues > unless you sit down and well design your abstraction layer for audio I/O. Worse-- the two fragment limit is passed on to the OSS emulation (or at least it was in 2005; but if this is still true for the ALSA API in 2007, then my guess is that it's also still true for the OSS emulation). The result is that applications written for OSS do not work anymore when using the OSS emulation of ALSA and therefore the argument of providing backwards compatibility doesn't exist. ...snip... > Hannu has ideas on how that could work. I suggest all of the kernel > developers listen, and listen well, or this mess will never be fixed in a > way that is truly usable. > > -nenolod Good post, nenolod. -- Carlo Wood <[EMAIL PROTECTED]> PS I am NOT saying that I want ALSA to be removed from the kernel. I am just saying that I agree with those who think that the ALSA API is too complex, hard to use and has serious flaws that should be addressed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Sat, Jul 07, 2007 at 02:41:05AM +, William Pitcock wrote: The most fucked up thing that I can think of about the current state of affairs in ALSA is dmix. Every other UNIX sound system like ALSA does it's software mixing in kernel space. The applications never even know about it. It's not only until recently (2005-2006 or so) that ALSA came close to this, but there are still problems. Many cards need workarounds to make dmix work because of the way it works, and the way that ALSA buffers data around. I have to agree. I am not an audio programmer, just a user; but the bottom line is simply: It is WAY to hard to get things working (if at all possible). At one point I tried to get sound from xmms and ut2004 at the same time (on my new machine). I was ASTONISHED that it didn't Just-Work! After trying many complex things-- I gave up and put my old soundblaster Live! in the new PC - because that card has hardware support for this. Now I was lucky to HAVE that other soundcard, but what about all those other users out there who just buy a new PC, with a sound chip on the motherboard and then, being simple, ordinairy users, have to face this ALSA configuration hell to do something as simple as having two audio applications play sound at the same time? For the non-technically inclined, ALSA only keeps two fragments for input/output data each. This is horribly unusable because most soundcard fragments are only 1KB, so applications have to adopt ringbuffers to pass data to ALSA. If you're doing video, this leads to possible timing issues unless you sit down and well design your abstraction layer for audio I/O. Worse-- the two fragment limit is passed on to the OSS emulation (or at least it was in 2005; but if this is still true for the ALSA API in 2007, then my guess is that it's also still true for the OSS emulation). The result is that applications written for OSS do not work anymore when using the OSS emulation of ALSA and therefore the argument of providing backwards compatibility doesn't exist. ...snip... Hannu has ideas on how that could work. I suggest all of the kernel developers listen, and listen well, or this mess will never be fixed in a way that is truly usable. -nenolod Good post, nenolod. -- Carlo Wood [EMAIL PROTECTED] PS I am NOT saying that I want ALSA to be removed from the kernel. I am just saying that I agree with those who think that the ALSA API is too complex, hard to use and has serious flaws that should be addressed. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OSS vs ALSA API (was Re: Is it time for remove (crap) ALSA from kernel tree ?)
Hi! Today both OSS and ALSA teams have to spend significant amounts of time in emulating the alien APIs. Making OSS and ALSA to co-exist will require some work in both sides but that should be nothing when compared to the effort required for emulation. ... In Linux we typically do not do two APIs and codebases for the same purpose. If we do, like sys_mmap and sys_mmap2, it's an older legacy interface that never changes, that we are moving people AWAY from, and a newer interface. I see no reason to change from the path at which upstream has arrived: OSS is a legacy API that's frozen in time, and ALSA provides the new stuff. While I agree that ALSA is better than OSS... I don't actually think ALSA kerneluser api is... at least for my purposes. I'm still using OSS emulation, because I could not get alsa proper to work... and the advanced stuff just does not work in emulation. In OSS days, if you wanted to test kernel sound driver, you did: mknod /dev/dsp cat /bin/bash /dev/dsp. With alsa+oss emulation, you need mknod /dev/mixer install aumix aumix mknod /dev/dsp cat /bin/bash /dev/dsp. With alsa proper, it is install alsalib create about 5 device nodes install alsautils maybe do some config? aplay some.wav ..provided you have .wav near you. I'm not sure if it is possible to produce sounds using normal shell scripting? (w/o alsautils)? I can even test kernel graphics drivers by cat /bin/bash /dev/fb0... it would be nice to have equivalent for audio... OSS API seems to be the equivalent these days, but please don't deprecate it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Hi! Soft mixing is actually the biggest issue because if you had generalized soft-mixing in the kernel-visible audio ports[1] you would win two things: - programs could use the OSS API without interfering with the ALSA one or which each other This works with aoss. If people often run into this problem it might make sense to deprecate the in-kernel OSS emulation and point people to the userspace emulation instead? Without in-kernel OSS emulation, it is very hard to verify if kernel sound support works properly. OSS could been driven from shell for testing, and I believe that's still important feature to keep. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Wed, 4 Jul 2007 19:32:29 +0200, Adrian Bunk wrote: On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote: I know this may sound kind of stupid, but how about not deprecating either, and fully supporting both sound systems? Maybe we can get them to work together, and the distro or user can choose whether they would like to use alsa or oss for that particular card (or have the distro choose the sound drivers that are best supported for that particular card). As it is now, most apps already support oss and alsa. It does not sound stupid and sounds good at first sight. But there are problems we've already seen with similar situations in different parts of the kernel: They would have different hardware support, features and bugs. And then a user user whose sound card is only supported by sound system A needs a feature only available in sound system B. And the quality decreases since people will often not report bugs in sound system A if sound system B works for them. OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's mostly a difference for application developers. And since (as you say) most applications already support both, there's no compelling reason for providing more than one of them. cu Adrian If the developers of ALSA made a nuclear reactor, it would have five different control panels for controlling the rods in the reactor core, and each would do something different and not what the documentation said. Actually, I lied about that. It wouldn't have any usable documentation. But, there would be a hidden feature that you could sound the overload alarm by pulling out the stapler in the control office. Useful feature, that. As an audio developer on Linux, I must say that developing with ALSA is absolute fucking hell. If there was a way where both APIs could natively be supported, more people would be happy with the current state of affairs in the kernel. The most fucked up thing that I can think of about the current state of affairs in ALSA is dmix. Every other UNIX sound system like ALSA does it's software mixing in kernel space. The applications never even know about it. It's not only until recently (2005-2006 or so) that ALSA came close to this, but there are still problems. Many cards need workarounds to make dmix work because of the way it works, and the way that ALSA buffers data around. For the non-technically inclined, ALSA only keeps two fragments for input/output data each. This is horribly unusable because most soundcard fragments are only 1KB, so applications have to adopt ringbuffers to pass data to ALSA. If you're doing video, this leads to possible timing issues unless you sit down and well design your abstraction layer for audio I/O. So people switch to things like JACK and PulseAudio because it's the only way they can get workable Audio I/O on ALSA. What's even worse for the ALSA API is that it's designed around lowlatency programming, but only a few drivers properly support it. Why do you need lowlatency access to play a beep or a ding or whatever? The simple answer is you don't. ALSA could and can be done correctly, but OSS4 is already here and provides an API which solves all of ALSA's current problems. So why waste time with that, when OSS4 is already here and more friendly to the developers of the software most Linux users use? If OSS4 and ALSA apis could run on the same base driver, then a lot more people will be happier, as there will be choice available in which API to use, e.g. OSS4 or the libasound self-abuse method. Hannu has ideas on how that could work. I suggest all of the kernel developers listen, and listen well, or this mess will never be fixed in a way that is truly usable. -nenolod - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Wed, 4 Jul 2007 19:32:29 +0200, Adrian Bunk wrote: On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote: I know this may sound kind of stupid, but how about not deprecating either, and fully supporting both sound systems? Maybe we can get them to work together, and the distro or user can choose whether they would like to use alsa or oss for that particular card (or have the distro choose the sound drivers that are best supported for that particular card). As it is now, most apps already support oss and alsa. It does not sound stupid and sounds good at first sight. But there are problems we've already seen with similar situations in different parts of the kernel: They would have different hardware support, features and bugs. And then a user user whose sound card is only supported by sound system A needs a feature only available in sound system B. And the quality decreases since people will often not report bugs in sound system A if sound system B works for them. OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's mostly a difference for application developers. And since (as you say) most applications already support both, there's no compelling reason for providing more than one of them. cu Adrian If the developers of ALSA made a nuclear reactor, it would have five different control panels for controlling the rods in the reactor core, and each would do something different and not what the documentation said. Actually, I lied about that. It wouldn't have any usable documentation. But, there would be a hidden feature that you could sound the overload alarm by pulling out the stapler in the control office. Useful feature, that. As an audio developer on Linux, I must say that developing with ALSA is absolute fucking hell. If there was a way where both APIs could natively be supported, more people would be happy with the current state of affairs in the kernel. The most fucked up thing that I can think of about the current state of affairs in ALSA is dmix. Every other UNIX sound system like ALSA does it's software mixing in kernel space. The applications never even know about it. It's not only until recently (2005-2006 or so) that ALSA came close to this, but there are still problems. Many cards need workarounds to make dmix work because of the way it works, and the way that ALSA buffers data around. For the non-technically inclined, ALSA only keeps two fragments for input/output data each. This is horribly unusable because most soundcard fragments are only 1KB, so applications have to adopt ringbuffers to pass data to ALSA. If you're doing video, this leads to possible timing issues unless you sit down and well design your abstraction layer for audio I/O. So people switch to things like JACK and PulseAudio because it's the only way they can get workable Audio I/O on ALSA. What's even worse for the ALSA API is that it's designed around lowlatency programming, but only a few drivers properly support it. Why do you need lowlatency access to play a beep or a ding or whatever? The simple answer is you don't. ALSA could and can be done correctly, but OSS4 is already here and provides an API which solves all of ALSA's current problems. So why waste time with that, when OSS4 is already here and more friendly to the developers of the software most Linux users use? If OSS4 and ALSA apis could run on the same base driver, then a lot more people will be happier, as there will be choice available in which API to use, e.g. OSS4 or the libasound self-abuse method. Hannu has ideas on how that could work. I suggest all of the kernel developers listen, and listen well, or this mess will never be fixed in a way that is truly usable. -nenolod - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Wed, 4 Jul 2007, Adrian Bunk wrote: On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote: I know this may sound kind of stupid, but how about not deprecating either, and fully supporting both sound systems? Maybe we can get them to work together, and the distro or user can choose whether they would like to use alsa or oss for that particular card (or have the distro choose the sound drivers that are best supported for that particular card). As it is now, most apps already support oss and alsa. It does not sound stupid and sounds good at first sight. But there are problems we've already seen with similar situations in different parts of the kernel: They would have different hardware support, features and bugs. And then a user user whose sound card is only supported by sound system A needs a feature only available in sound system B. And the quality decreases since people will often not report bugs in sound system A if sound system B works for them. OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's mostly a difference for application developers. And since (as you say) most applications already support both, there's no compelling reason for providing more than one of them. From Hannu message: "I think the ideal solution would be that both ALSA and OSS APIs can co-exist by sharing the same low level drivers (which has already been demonstrated). The low level driver interfaces in both systems are practically identical. This means that ALSA's core can work with OSS' drivers and vice versa." So Hannu have plan for share ALSA low level drivers without changes (porting to OSS will not be neccessary and/or will need only small amount of time .. IMO much less than make ALSA fully functional). Main diffrences between ALSA and OSS are above low level drivers so IMO it is completly possible have ALSA and OSS in the same tree. OSS wtil not dies (and try resurect) ALSA still (after few years) was not born and still isn't rock solid point odf Linux desktop (IMO it is most weeknes ponit of LD). IMO it will be better if Hannu will start pushing any OSS chages to Linus tree. Current OSS code in Linus tree is more or less not useable so allow maintain this code in main tree can't hurd anything outside this area. kloczek -- --- *Ludzie nie mają problemów, tylko sobie sami je stwarzają* --- Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED]
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Wed, 4 Jul 2007, Adrian Bunk wrote: On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote: I know this may sound kind of stupid, but how about not deprecating either, and fully supporting both sound systems? Maybe we can get them to work together, and the distro or user can choose whether they would like to use alsa or oss for that particular card (or have the distro choose the sound drivers that are best supported for that particular card). As it is now, most apps already support oss and alsa. It does not sound stupid and sounds good at first sight. But there are problems we've already seen with similar situations in different parts of the kernel: They would have different hardware support, features and bugs. And then a user user whose sound card is only supported by sound system A needs a feature only available in sound system B. And the quality decreases since people will often not report bugs in sound system A if sound system B works for them. OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's mostly a difference for application developers. And since (as you say) most applications already support both, there's no compelling reason for providing more than one of them. From Hannu message: I think the ideal solution would be that both ALSA and OSS APIs can co-exist by sharing the same low level drivers (which has already been demonstrated). The low level driver interfaces in both systems are practically identical. This means that ALSA's core can work with OSS' drivers and vice versa. So Hannu have plan for share ALSA low level drivers without changes (porting to OSS will not be neccessary and/or will need only small amount of time .. IMO much less than make ALSA fully functional). Main diffrences between ALSA and OSS are above low level drivers so IMO it is completly possible have ALSA and OSS in the same tree. OSS wtil not dies (and try resurect) ALSA still (after few years) was not born and still isn't rock solid point odf Linux desktop (IMO it is most weeknes ponit of LD). IMO it will be better if Hannu will start pushing any OSS chages to Linus tree. Current OSS code in Linus tree is more or less not useable so allow maintain this code in main tree can't hurd anything outside this area. kloczek -- --- *Ludzie nie mają problemów, tylko sobie sami je stwarzają* --- Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED]
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote: > > I know this may sound kind of stupid, but how about not deprecating either, > and fully supporting both sound systems? Maybe we can get them to work > together, and the distro or user can choose whether they would like to use > alsa or oss for that particular card (or have the distro choose the sound > drivers that are best supported for that particular card). As it is now, > most apps already support oss and alsa. It does not sound stupid and sounds good at first sight. But there are problems we've already seen with similar situations in different parts of the kernel: They would have different hardware support, features and bugs. And then a user user whose sound card is only supported by sound system A needs a feature only available in sound system B. And the quality decreases since people will often not report bugs in sound system A if sound system B works for them. OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's mostly a difference for application developers. And since (as you say) most applications already support both, there's no compelling reason for providing more than one of them. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Tomasz Kłoczko wrote: Few dayas ago OSS source code was oppened uder CDDL for Solaris and GLPv2 for Linux: http://www.opensound.com/press/2007/oss-gpl-cddl.txt So this source without problems code can be integragrated in Linus tree and after this Linux can provide much better soud supoport than with current ALSA. Any plans for doing this ? kloczek I know this may sound kind of stupid, but how about not deprecating either, and fully supporting both sound systems? Maybe we can get them to work together, and the distro or user can choose whether they would like to use alsa or oss for that particular card (or have the distro choose the sound drivers that are best supported for that particular card). As it is now, most apps already support oss and alsa. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Tomasz Kłoczko wrote: Few dayas ago OSS source code was oppened uder CDDL for Solaris and GLPv2 for Linux: http://www.opensound.com/press/2007/oss-gpl-cddl.txt So this source without problems code can be integragrated in Linus tree and after this Linux can provide much better soud supoport than with current ALSA. Any plans for doing this ? kloczek I know this may sound kind of stupid, but how about not deprecating either, and fully supporting both sound systems? Maybe we can get them to work together, and the distro or user can choose whether they would like to use alsa or oss for that particular card (or have the distro choose the sound drivers that are best supported for that particular card). As it is now, most apps already support oss and alsa. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote: I know this may sound kind of stupid, but how about not deprecating either, and fully supporting both sound systems? Maybe we can get them to work together, and the distro or user can choose whether they would like to use alsa or oss for that particular card (or have the distro choose the sound drivers that are best supported for that particular card). As it is now, most apps already support oss and alsa. It does not sound stupid and sounds good at first sight. But there are problems we've already seen with similar situations in different parts of the kernel: They would have different hardware support, features and bugs. And then a user user whose sound card is only supported by sound system A needs a feature only available in sound system B. And the quality decreases since people will often not report bugs in sound system A if sound system B works for them. OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's mostly a difference for application developers. And since (as you say) most applications already support both, there's no compelling reason for providing more than one of them. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
> > Well, had a look at what FUSD does. It assumes that the ioctl > > argument is stuctured according to the command. If all OSS ioctls are > > like that, then fine, fuse can support it properly. > > > > The drawback of this is that ioctls which aren't structured properly > > could cause weird failures due to wrong data being accessed by the > > poor unknowing kernel. > > Included with the docs there's a list of the OSS ioctls. I don't understand > enough of the problem to judge whether they are suitable to be handled by > FUSE: > > http://manuals.opensound.com/developer/ioctl.html [version 4] > http://www.4front-tech.com/pguide/oss.pdf [version 3] > > I don't know which API version is supposed to be supported though. Thanks, but these docs are about what the ioctls do, and I'm totally uninterested in that. What I'm interested is how the ioctl data is _structured_. OK, had a look at , it does define a data structuring based on the ioctl numbers, and it's just slightly different from the structuring defined by . Oh, the beauty of the ioctls. So answering my own question: no, it's not sanely possible to support ioctls through fuse without userspace hacks or significant effort. A possibly acceptable option is to add a plugin mechanism, whereby people could write small ioctl interpreter kernel modules for their specific needs (such as parsing OSS ioctls), which would serialize/deserialize any type of ioctl input/output making them suitable for transfering between the kernel and the userspace filesystem. Another, much more complex option is to design a generic ioctl data interpreter language, and let the filesystem upload their ioctl parsers into the kernel. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Friday 29 June 2007, Miklos Szeredi wrote: > > > > Not as if it would be hard to add ioctl support to fuse. What fuse > > > > can't handle is the data argument of ioctl(), so the most it could do > > > > is give the filesystem a pid (tid) and a virtual address. The > > > > userspace fs could then get/put the data through /proc//mem. > > > > > > Hork... > > > > > > Identify the generic ioctls that are relevant to a FUSE file system and > > > have real meaning *and* are useful. > > > > I don't think there are any such. > > > > The point in this thread was I think about emulating an OSS sound > > device through a fuse fs. In that case fuse would need _generic_ > > ioctl support, which simply can't be done without weird userspace > > hacks. > > Well, had a look at what FUSD does. It assumes that the ioctl > argument is stuctured according to the command. If all OSS ioctls are > like that, then fine, fuse can support it properly. > > The drawback of this is that ioctls which aren't structured properly > could cause weird failures due to wrong data being accessed by the > poor unknowing kernel. > > Miklos Included with the docs there's a list of the OSS ioctls. I don't understand enough of the problem to judge whether they are suitable to be handled by FUSE: http://manuals.opensound.com/developer/ioctl.html [version 4] http://www.4front-tech.com/pguide/oss.pdf [version 3] I don't know which API version is supposed to be supported though. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Friday 29 June 2007, Miklos Szeredi wrote: Not as if it would be hard to add ioctl support to fuse. What fuse can't handle is the data argument of ioctl(), so the most it could do is give the filesystem a pid (tid) and a virtual address. The userspace fs could then get/put the data through /proc/pid/mem. Hork... Identify the generic ioctls that are relevant to a FUSE file system and have real meaning *and* are useful. I don't think there are any such. The point in this thread was I think about emulating an OSS sound device through a fuse fs. In that case fuse would need _generic_ ioctl support, which simply can't be done without weird userspace hacks. Well, had a look at what FUSD does. It assumes that the ioctl argument is stuctured according to the command. If all OSS ioctls are like that, then fine, fuse can support it properly. The drawback of this is that ioctls which aren't structured properly could cause weird failures due to wrong data being accessed by the poor unknowing kernel. Miklos Included with the docs there's a list of the OSS ioctls. I don't understand enough of the problem to judge whether they are suitable to be handled by FUSE: http://manuals.opensound.com/developer/ioctl.html [version 4] http://www.4front-tech.com/pguide/oss.pdf [version 3] I don't know which API version is supposed to be supported though. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Well, had a look at what FUSD does. It assumes that the ioctl argument is stuctured according to the command. If all OSS ioctls are like that, then fine, fuse can support it properly. The drawback of this is that ioctls which aren't structured properly could cause weird failures due to wrong data being accessed by the poor unknowing kernel. Included with the docs there's a list of the OSS ioctls. I don't understand enough of the problem to judge whether they are suitable to be handled by FUSE: http://manuals.opensound.com/developer/ioctl.html [version 4] http://www.4front-tech.com/pguide/oss.pdf [version 3] I don't know which API version is supposed to be supported though. Thanks, but these docs are about what the ioctls do, and I'm totally uninterested in that. What I'm interested is how the ioctl data is _structured_. OK, had a look at linux/soundcard.h, it does define a data structuring based on the ioctl numbers, and it's just slightly different from the structuring defined by asm-generic/ioctl.h. Oh, the beauty of the ioctls. So answering my own question: no, it's not sanely possible to support ioctls through fuse without userspace hacks or significant effort. A possibly acceptable option is to add a plugin mechanism, whereby people could write small ioctl interpreter kernel modules for their specific needs (such as parsing OSS ioctls), which would serialize/deserialize any type of ioctl input/output making them suitable for transfering between the kernel and the userspace filesystem. Another, much more complex option is to design a generic ioctl data interpreter language, and let the filesystem upload their ioctl parsers into the kernel. Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Robert Hancock shaw.ca> writes: > In the case of S/PDIF output on ice1724 (and probably other cards), it > would be nice if ALSA defaulted to routing default audio to both the > S/PDIF and analog ports, as this is what most users would normally > expect.. The Windows drivers work like that, but on Linux you have to > pick one or the other (at least without a bunch of mucking with the > config file). I believe some cards can't do this in fact which might be argument due to consistency. Otherwise I don't so much have an opinion on whether or not this should be default though... Rene - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
> > > Not as if it would be hard to add ioctl support to fuse. What fuse > > > can't handle is the data argument of ioctl(), so the most it could do > > > is give the filesystem a pid (tid) and a virtual address. The > > > userspace fs could then get/put the data through /proc//mem. > > > > Hork... > > > > Identify the generic ioctls that are relevant to a FUSE file system and > > have real meaning *and* are useful. > > I don't think there are any such. > > The point in this thread was I think about emulating an OSS sound > device through a fuse fs. In that case fuse would need _generic_ > ioctl support, which simply can't be done without weird userspace > hacks. Well, had a look at what FUSD does. It assumes that the ioctl argument is stuctured according to the command. If all OSS ioctls are like that, then fine, fuse can support it properly. The drawback of this is that ioctls which aren't structured properly could cause weird failures due to wrong data being accessed by the poor unknowing kernel. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
> Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > Not as if it would be hard to add ioctl support to fuse. What fuse > > can't handle is the data argument of ioctl(), so the most it could do > > is give the filesystem a pid (tid) and a virtual address. The > > userspace fs could then get/put the data through /proc//mem. > > Hork... > > Identify the generic ioctls that are relevant to a FUSE file system and > have real meaning *and* are useful. I don't think there are any such. The point in this thread was I think about emulating an OSS sound device through a fuse fs. In that case fuse would need _generic_ ioctl support, which simply can't be done without weird userspace hacks. I'm definitely not adding specific ioctls to fuse. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Fri, 29 Jun 2007 16:56:05 +0200
Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> Not as if it would be hard to add ioctl support to fuse. What fuse
> can't handle is the data argument of ioctl(), so the most it could do
> is give the filesystem a pid (tid) and a virtual address. The
> userspace fs could then get/put the data through /proc//mem.
Hork...
Identify the generic ioctls that are relevant to a FUSE file system and
have real meaning *and* are useful. Teach fuse to turn those to and from
messages properly and if you must add any others (ie if there is good
reason to want them then add a single FUSEFS ioctl something like
struct fusefs_ioctl {
u32 opcode;
void *data_in;
void *data_out;
u16 size_in;
u16 size_out;
}
so that anything totally weird can be passed through without
horrible /proc/... hacks and without putting tons of cases into FUSE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
> I suppose the best way to provide OSS emu is to use something like > FUSD [similar to the OSS2JACK package] [1] to provide the OSS device > files and then redirect to user space, so all ALSA pcm devices can > be used.. Sadly FUSD doesn't really get actively developed anymore > it seems. And FUSE can't handle ioctls. Not as if it would be hard to add ioctl support to fuse. What fuse can't handle is the data argument of ioctl(), so the most it could do is give the filesystem a pid (tid) and a virtual address. The userspace fs could then get/put the data through /proc//mem. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Anton Petrusevich wrote: Is there a tool which can be used to configure .asoundrc? There is an QT4 based one [1] and a somewhat old KDE based tool [2]. Regards, Gabriel C [1] http://sourceforge.net/projects/aplugedit/ [2] http://sourceforge.net/projects/kasound/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Friday 29 June 2007, Anton Petrusevich wrote: > On Friday 29 June 2007 12:30:54 Florian Schmidt wrote: > > Sadly it seems pretty much everyone, especially closed source apps get > > this wrong (but to be fair: loads of open source software gets it wrong, > > too, ekiga for example). > > Isn't that because there's a perferct documentation for programming ALSA > but authors of those apps can't read? No, like i said, the docs are unclear on these issues :) That's why so many people get it wrong. > But in real life I have to use flashplayer, for example. Yes, in these cases flashplayer should use either the default pcm device [which the user can then tweak to his liking] or provide some means to configure it. for example via a dotfile in the user's homedir. This is not ALSA's fault. > I am with Linux since 1997, I know bunch of them. I used to use XEmacs, but > now I prefer VIM. But I am not a .asoundrc programmer, I want to be just a > user. I agree that it would be nice to have a tool to select the default device in ALSA. > > But skype is a piece of crap anyways. It also doesn't get any sounds out > > of my other [non ice1712] card. Neither in OSS nor in ALSA mode. Not a > > beep. And yeah, the device is available [and even has hardware > > multiplexing].. > > > > But 99.9% of problems people have with ALSA are due to badly coded apps.. > > "Those apps are crap and ALSA is perfect". I hoped some ALSA-developers > would think of improving usability of ALSA, or I would not talk here. ALSA must be improved, too. But that doesn't change a thing about these apps misusing the ALSA API and people blaming ALSA lateron. Which is wrong. > It's good that people are not thinking that ALSA is already perfect, it > leaves us (me) a hope it will be improved. I don't think any serious person believes that ALSA is perfect :) Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thursday 28 June 2007, Adrian Bunk wrote: > There is also a userspace OSS emulation for ALSA not suffering from > these problems. Yeah, it suffers from other problems though. It uses an LD_PRELOAD hack to intercept library calls that open the /dev/dsp devices etc.. This doesn't always work. I suppose the best way to provide OSS emu is to use something like FUSD [similar to the OSS2JACK package] [1] to provide the OSS device files and then redirect to user space, so all ALSA pcm devices can be used.. Sadly FUSD doesn't really get actively developed anymore it seems. And FUSE can't handle ioctls. [1] http://www.circlemud.org/~jelson/software/fusd/ Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Friday 29 June 2007 12:30:54 Florian Schmidt wrote: > Sadly it seems pretty much everyone, especially closed source apps get this > wrong (but to be fair: loads of open source software gets it wrong, too, > ekiga for example). Isn't that because there's a perferct documentation for programming ALSA but authors of those apps can't read? > Well, like i said, the application in question should allow you to enter > any pcm name you want. If it doesn't it's broken. But in real life I have to use flashplayer, for example. > I don't know of any. But any text editor will do. I am with Linux since 1997, I know bunch of them. I used to use XEmacs, but now I prefer VIM. But I am not a .asoundrc programmer, I want to be just a user. > The flashplayer has been another one of these badly coded apps ;) Maybe > that has changed in recent releases. [...] > But skype is a piece of crap anyways. It also doesn't get any sounds out of > my other [non ice1712] card. Neither in OSS nor in ALSA mode. Not a beep. > And yeah, the device is available [and even has hardware multiplexing].. > But 99.9% of problems people have with ALSA are due to badly coded apps.. "Those apps are crap and ALSA is perfect". I hoped some ALSA-developers would think of improving usability of ALSA, or I would not talk here. > I agree. ALSA is not very userfriendly. Especially the missing proper > device enumeration support is a problem. It's good that people are not thinking that ALSA is already perfect, it leaves us (me) a hope it will be improved. -- Anton Petrusevich - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thursday 28 June 2007, Anton Petrusevich wrote:
> > > I have ICE1724, a very good sound card to my taste, works like a charm.
> > > But with ALSA I had a really hard time to configure it properly, wanna
> > > see my .asoundrc?
> >
> > Not particularly. I don't count as a great fan of the config file syntax
> > and don't use any configuration myself.
>
> Do you have an SPDIF out? If you don't then you don't need .asoundrc of
> course.
With a properly coded ALSA app, one doesn't need a .asoundrc. You would
enter "plug:spdif" [or something similar] into the pcm device name entry text
field.
Or if you want to point all apps to that device you actually could add this to
your .asoundrc:
pcm.!default {
type plug
slace.pcm "spdif"
}
[or something similar. Too lazy to look up the exact syntax now]. And then
every app using the ALSA API _correctly_ should use that device [if
configured to use the default device, which should be the _default_ ;)]
Sadly it seems pretty much everyone, especially closed source apps get this
wrong (but to be fair: loads of open source software gets it wrong, too,
ekiga for example).
What they do wrong is that they try to present a list of devices to the user
from which he can choose [which isn't bad in itself] and also do _not_ offer
any way to specify an arbitrary PCM device name.
Sadly, the ALSA api docs do not stress this point often enough, so it gets
missed pretty often.
I once posted an [not original, i suppose people before me got that idea, too]
idea to the alsa-dev list a while back, proposing a way to be able
to "register" pcm devices defined in .asoundrc/asound.conf, so that apps that
want to present a list to the user can simply ask ALSA for a list of devices
nd hav the user defined ones included. Sadly i don't think it ever went
anywhere..
> Because I want to route it differently, sometimes to spdif, sometimes to
> headphones, sometimes to mix sounds from different apps. Well, my config
> may be a bit ancient as it was written when dmix was not default.
Well, like i said, the application in question should allow you to enter any
pcm name you want. If it doesn't it's broken.
> I have read some advices for ice1724 already. The main reason I wrote to
> lkml -- I hate .asounrc and reading docs about it. I hate "flexebility"
> that requires restarting apps after changing sound routes.
I own a ice1712, too, but i only use it for JACK and it works brilliantly
there. But i know it can be a bitch to configure since it sports a 10/12
channel device which can be too complicated for some ALSA apps making
assumptions about the device they get ;)
> I perfectly know this one. I would like to use some really user-friendly
> tool.
I don't know of any. But any text editor will do.
> > > I want to be able to hear sound from flashplayer on my reciever or in
> > > my headphones -- how?
> >
> > Not sure? Is your receiver on an analog output and are your headphones
>
> My receiver is on spdif out.
The flashplayer has been another one of these badly coded apps ;) Maybe that
has changed in recent releases.
> > It's not working without an .asoundrc?
>
> Looks like it's not working with. As skype is not so informative.
But skype is a piece of crap anyways. It also doesn't get any sounds out of my
other [non ice1712] card. Neither in OSS nor in ALSA mode. Not a beep. And
yeah, the device is available [and even has hardware multiplexing]..
> I am not about ice1724 or .asounrc here. I am trying to talk about
> user-friendliness of ALSA. It's very unfriendly.
I agree. ALSA is not very userfriendly. Especially the missing proper device
enumeration support is a problem.
But 99.9% of problems people have with ALSA are due to badly coded apps..
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thursday 28 June 2007, Anton Petrusevich wrote:
I have ICE1724, a very good sound card to my taste, works like a charm.
But with ALSA I had a really hard time to configure it properly, wanna
see my .asoundrc?
Not particularly. I don't count as a great fan of the config file syntax
and don't use any configuration myself.
Do you have an SPDIF out? If you don't then you don't need .asoundrc of
course.
With a properly coded ALSA app, one doesn't need a .asoundrc. You would
enter plug:spdif [or something similar] into the pcm device name entry text
field.
Or if you want to point all apps to that device you actually could add this to
your .asoundrc:
pcm.!default {
type plug
slace.pcm spdif
}
[or something similar. Too lazy to look up the exact syntax now]. And then
every app using the ALSA API _correctly_ should use that device [if
configured to use the default device, which should be the _default_ ;)]
Sadly it seems pretty much everyone, especially closed source apps get this
wrong (but to be fair: loads of open source software gets it wrong, too,
ekiga for example).
What they do wrong is that they try to present a list of devices to the user
from which he can choose [which isn't bad in itself] and also do _not_ offer
any way to specify an arbitrary PCM device name.
Sadly, the ALSA api docs do not stress this point often enough, so it gets
missed pretty often.
I once posted an [not original, i suppose people before me got that idea, too]
idea to the alsa-dev list a while back, proposing a way to be able
to register pcm devices defined in .asoundrc/asound.conf, so that apps that
want to present a list to the user can simply ask ALSA for a list of devices
nd hav the user defined ones included. Sadly i don't think it ever went
anywhere..
Because I want to route it differently, sometimes to spdif, sometimes to
headphones, sometimes to mix sounds from different apps. Well, my config
may be a bit ancient as it was written when dmix was not default.
Well, like i said, the application in question should allow you to enter any
pcm name you want. If it doesn't it's broken.
I have read some advices for ice1724 already. The main reason I wrote to
lkml -- I hate .asounrc and reading docs about it. I hate flexebility
that requires restarting apps after changing sound routes.
I own a ice1712, too, but i only use it for JACK and it works brilliantly
there. But i know it can be a bitch to configure since it sports a 10/12
channel device which can be too complicated for some ALSA apps making
assumptions about the device they get ;)
I perfectly know this one. I would like to use some really user-friendly
tool.
I don't know of any. But any text editor will do.
I want to be able to hear sound from flashplayer on my reciever or in
my headphones -- how?
Not sure? Is your receiver on an analog output and are your headphones
My receiver is on spdif out.
The flashplayer has been another one of these badly coded apps ;) Maybe that
has changed in recent releases.
It's not working without an .asoundrc?
Looks like it's not working with. As skype is not so informative.
But skype is a piece of crap anyways. It also doesn't get any sounds out of my
other [non ice1712] card. Neither in OSS nor in ALSA mode. Not a beep. And
yeah, the device is available [and even has hardware multiplexing]..
I am not about ice1724 or .asounrc here. I am trying to talk about
user-friendliness of ALSA. It's very unfriendly.
I agree. ALSA is not very userfriendly. Especially the missing proper device
enumeration support is a problem.
But 99.9% of problems people have with ALSA are due to badly coded apps..
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thursday 28 June 2007, Adrian Bunk wrote: There is also a userspace OSS emulation for ALSA not suffering from these problems. Yeah, it suffers from other problems though. It uses an LD_PRELOAD hack to intercept library calls that open the /dev/dsp devices etc.. This doesn't always work. I suppose the best way to provide OSS emu is to use something like FUSD [similar to the OSS2JACK package] [1] to provide the OSS device files and then redirect to user space, so all ALSA pcm devices can be used.. Sadly FUSD doesn't really get actively developed anymore it seems. And FUSE can't handle ioctls. [1] http://www.circlemud.org/~jelson/software/fusd/ Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Friday 29 June 2007 12:30:54 Florian Schmidt wrote: Sadly it seems pretty much everyone, especially closed source apps get this wrong (but to be fair: loads of open source software gets it wrong, too, ekiga for example). Isn't that because there's a perferct documentation for programming ALSA but authors of those apps can't read? Well, like i said, the application in question should allow you to enter any pcm name you want. If it doesn't it's broken. But in real life I have to use flashplayer, for example. I don't know of any. But any text editor will do. I am with Linux since 1997, I know bunch of them. I used to use XEmacs, but now I prefer VIM. But I am not a .asoundrc programmer, I want to be just a user. The flashplayer has been another one of these badly coded apps ;) Maybe that has changed in recent releases. [...] But skype is a piece of crap anyways. It also doesn't get any sounds out of my other [non ice1712] card. Neither in OSS nor in ALSA mode. Not a beep. And yeah, the device is available [and even has hardware multiplexing].. But 99.9% of problems people have with ALSA are due to badly coded apps.. Those apps are crap and ALSA is perfect. I hoped some ALSA-developers would think of improving usability of ALSA, or I would not talk here. I agree. ALSA is not very userfriendly. Especially the missing proper device enumeration support is a problem. It's good that people are not thinking that ALSA is already perfect, it leaves us (me) a hope it will be improved. -- Anton Petrusevich - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Friday 29 June 2007, Anton Petrusevich wrote: On Friday 29 June 2007 12:30:54 Florian Schmidt wrote: Sadly it seems pretty much everyone, especially closed source apps get this wrong (but to be fair: loads of open source software gets it wrong, too, ekiga for example). Isn't that because there's a perferct documentation for programming ALSA but authors of those apps can't read? No, like i said, the docs are unclear on these issues :) That's why so many people get it wrong. But in real life I have to use flashplayer, for example. Yes, in these cases flashplayer should use either the default pcm device [which the user can then tweak to his liking] or provide some means to configure it. for example via a dotfile in the user's homedir. This is not ALSA's fault. I am with Linux since 1997, I know bunch of them. I used to use XEmacs, but now I prefer VIM. But I am not a .asoundrc programmer, I want to be just a user. I agree that it would be nice to have a tool to select the default device in ALSA. But skype is a piece of crap anyways. It also doesn't get any sounds out of my other [non ice1712] card. Neither in OSS nor in ALSA mode. Not a beep. And yeah, the device is available [and even has hardware multiplexing].. But 99.9% of problems people have with ALSA are due to badly coded apps.. Those apps are crap and ALSA is perfect. I hoped some ALSA-developers would think of improving usability of ALSA, or I would not talk here. ALSA must be improved, too. But that doesn't change a thing about these apps misusing the ALSA API and people blaming ALSA lateron. Which is wrong. It's good that people are not thinking that ALSA is already perfect, it leaves us (me) a hope it will be improved. I don't think any serious person believes that ALSA is perfect :) Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Anton Petrusevich wrote: Is there a tool which can be used to configure .asoundrc? There is an QT4 based one [1] and a somewhat old KDE based tool [2]. Regards, Gabriel C [1] http://sourceforge.net/projects/aplugedit/ [2] http://sourceforge.net/projects/kasound/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
I suppose the best way to provide OSS emu is to use something like FUSD [similar to the OSS2JACK package] [1] to provide the OSS device files and then redirect to user space, so all ALSA pcm devices can be used.. Sadly FUSD doesn't really get actively developed anymore it seems. And FUSE can't handle ioctls. Not as if it would be hard to add ioctl support to fuse. What fuse can't handle is the data argument of ioctl(), so the most it could do is give the filesystem a pid (tid) and a virtual address. The userspace fs could then get/put the data through /proc/pid/mem. Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Fri, 29 Jun 2007 16:56:05 +0200
Miklos Szeredi [EMAIL PROTECTED] wrote:
Not as if it would be hard to add ioctl support to fuse. What fuse
can't handle is the data argument of ioctl(), so the most it could do
is give the filesystem a pid (tid) and a virtual address. The
userspace fs could then get/put the data through /proc/pid/mem.
Hork...
Identify the generic ioctls that are relevant to a FUSE file system and
have real meaning *and* are useful. Teach fuse to turn those to and from
messages properly and if you must add any others (ie if there is good
reason to want them then add a single FUSEFS ioctl something like
struct fusefs_ioctl {
u32 opcode;
void *data_in;
void *data_out;
u16 size_in;
u16 size_out;
}
so that anything totally weird can be passed through without
horrible /proc/... hacks and without putting tons of cases into FUSE
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Not as if it would be hard to add ioctl support to fuse. What fuse can't handle is the data argument of ioctl(), so the most it could do is give the filesystem a pid (tid) and a virtual address. The userspace fs could then get/put the data through /proc/pid/mem. Hork... Identify the generic ioctls that are relevant to a FUSE file system and have real meaning *and* are useful. I don't think there are any such. The point in this thread was I think about emulating an OSS sound device through a fuse fs. In that case fuse would need _generic_ ioctl support, which simply can't be done without weird userspace hacks. Well, had a look at what FUSD does. It assumes that the ioctl argument is stuctured according to the command. If all OSS ioctls are like that, then fine, fuse can support it properly. The drawback of this is that ioctls which aren't structured properly could cause weird failures due to wrong data being accessed by the poor unknowing kernel. Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Miklos Szeredi [EMAIL PROTECTED] wrote: Not as if it would be hard to add ioctl support to fuse. What fuse can't handle is the data argument of ioctl(), so the most it could do is give the filesystem a pid (tid) and a virtual address. The userspace fs could then get/put the data through /proc/pid/mem. Hork... Identify the generic ioctls that are relevant to a FUSE file system and have real meaning *and* are useful. I don't think there are any such. The point in this thread was I think about emulating an OSS sound device through a fuse fs. In that case fuse would need _generic_ ioctl support, which simply can't be done without weird userspace hacks. I'm definitely not adding specific ioctls to fuse. Miklos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Robert Hancock hancockr at shaw.ca writes: In the case of S/PDIF output on ice1724 (and probably other cards), it would be nice if ALSA defaulted to routing default audio to both the S/PDIF and analog ports, as this is what most users would normally expect.. The Windows drivers work like that, but on Linux you have to pick one or the other (at least without a bunch of mucking with the config file). I believe some cards can't do this in fact which might be argument due to consistency. Otherwise I don't so much have an opinion on whether or not this should be default though... Rene - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Anton Petrusevich wrote: On Thursday 28 June 2007 17:02:55 you wrote: Please always use Reply-to-All on this list -- subscribers here like to also get personal copies. I am not subscribed to linux-kernel, I am reading it on the web. I have ICE1724, a very good sound card to my taste, works like a charm. But with ALSA I had a really hard time to configure it properly, wanna see my .asoundrc? Not particularly. I don't count as a great fan of the config file syntax and don't use any configuration myself. Do you have an SPDIF out? If you don't then you don't need .asoundrc of course. The first thing I don't know is why you need an .asoundrc at all. Because I want to route it differently, sometimes to spdif, sometimes to headphones, sometimes to mix sounds from different apps. Well, my config may be a bit ancient as it was written when dmix was not default. I've CCed the alsa-user list -- some subscribers to it probably have experience with ice1724 and might be able to get you specific advice if you want. I have read some advices for ice1724 already. The main reason I wrote to lkml -- I hate .asounrc and reading docs about it. I hate "flexebility" that requires restarting apps after changing sound routes. Is there a tool which can be used to configure .asoundrc? vi. I perfectly know this one. I would like to use some really user-friendly tool. I want to be able to hear sound from flashplayer on my reciever or in my headphones -- how? Not sure? Is your receiver on an analog output and are your headphones My receiver is on spdif out. connected directly to a card output as well? In that case, "or" would seem to be just a mixer issue, and "and" would be dependent on hardware abilities and needs someone who knows your specific card and setup. It's not quite clear to me how to get full duplex working with my .asoundrc. It's not working without an .asoundrc? Looks like it's not working with. As skype is not so informative. But -- I'll personally not continue this very specific subthread simply due to not having the hardware, nor great generic experience with an .asounrc due to not needing it myself. When I do use one, I alway start by googling up a few examples and take it from there. Perhaps someone from alsa-user will step in. I am not about ice1724 or .asounrc here. I am trying to talk about user-friendliness of ALSA. It's very unfriendly. In the case of S/PDIF output on ice1724 (and probably other cards), it would be nice if ALSA defaulted to routing default audio to both the S/PDIF and analog ports, as this is what most users would normally expect.. The Windows drivers work like that, but on Linux you have to pick one or the other (at least without a bunch of mucking with the config file). -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 28 Jun 2007, Adrian Bunk outgrape: > Linux software not supporting ALSA has becoming quite esoteric. Indeed. This is why I haven't moaned much (or at all): aoss is ugly, sure, but you only need it for those rare apps which run for a long time or while other sounds are playing, on non-mixing-capable hardware, for which the in-kernel emulation won't suit... and most non-sound- specialist apps are using esd, arts or pulseaudio anyway, so that does the mixing for you (and pulseaudio also does it for every ALSA app if the pulseaudio plugin is installed). And the sound-specialist apps are the ones that actually *benefit* from ALSA's ludicrous degree of low-levelness, so they're using it, or something even more flexible like JACK. I use quite a lot of sound apps, and I can count the number of times I've had to use aoss in the last year on the fingers of one hand. But still it's conceptually ugly. Doing stuff in userspace, yes: but the kernel should be calling *back* to userspace to do it, not depending on things being done in the client's address space by a client library for proper function. (See also others' rants regarding the nasty quasi-unstable nature of the ALSA ioctl() kernel interface...) Isn't this sort of big user-to-and-from-kernelspace data-transfer job what we have relayfs for? (Or is it unidirectional?) > common. And that's exactly the case where users run into the results of > the "internal implementation detail" that their application used the > in-kernel OSS emulation instead of ALSA resulting in exactly these > problems. > > There is also a userspace OSS emulation for ALSA not suffering from > these problems. The problem is that the user has to *know* to run `aoss'. The in-kernel OSS emulation is actually nicer than thr userspace one because it works automatically without the user having to do a damned thing. If only it (and ALSA as a whole) called out to userspace again to mix, we could presumably ditch aoss, and the user would never need to care which API the author chose to use. (There are still complexities involving reading the user's .asoundrc to consider, but most users don't use that so wouldn't need aoss for anything anymore.) And then all these damn silly ALSA/OSS flamewars could go away. > It's not my decision whether or not to remove the in-kernel OSS emulation, > all I'm saying is that removing it might actually result in less users > having problems. I think it would lead to *more* problems. The in-kernel emulation *almost* Just Works, and surely the ideal we should aim for is an emulation that Just Works. -- `... in the sense that dragons logically follow evolution so they would be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep furiously - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 11:06 PM, Adrian Bunk wrote: The interesting point is that what you call "internal implementation details" is much _more_ exposed with the OSS emulation in the kernel _enabled_. Why? Linux software not supporting ALSA has becoming quite esoteric. But software like mplayer supporting both and trying OSS first and software supporting both and letting the user choose is today much more common. And that's exactly the case where users run into the results of the "internal implementation detail" that their application used the in-kernel OSS emulation instead of ALSA resulting in exactly these problems. There is also a userspace OSS emulation for ALSA not suffering from these problems. It's not my decision whether or not to remove the in-kernel OSS emulation, all I'm saying is that removing it might actually result in less users having problems. For what it's worth -- I do agree with this... Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thu, Jun 28, 2007 at 07:30:36PM +0100, Nix wrote: > On 25 Jun 2007, Adrian Bunk stated: > > If people often run into this problem it might make sense to deprecate > > the in-kernel OSS emulation and point people to the userspace emulation > > instead? > > So now people need to know internal implementation details like if a > program uses ALSA or OSS interfaces before they know how to *run* it? > > That doesn't sound especially nice to use (and before you say > `distributors will do it', not all programs are built by distributors). The interesting point is that what you call "internal implementation details" is much _more_ exposed with the OSS emulation in the kernel _enabled_. Why? Linux software not supporting ALSA has becoming quite esoteric. But software like mplayer supporting both and trying OSS first and software supporting both and letting the user choose is today much more common. And that's exactly the case where users run into the results of the "internal implementation detail" that their application used the in-kernel OSS emulation instead of ALSA resulting in exactly these problems. There is also a userspace OSS emulation for ALSA not suffering from these problems. It's not my decision whether or not to remove the in-kernel OSS emulation, all I'm saying is that removing it might actually result in less users having problems. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thu, Jun 28, 2007 at 04:20:45PM -0400, Lee Revell wrote: > On 6/28/07, Rene Herman <[EMAIL PROTECTED]> wrote: >> ALSA has been the Linux soundsystem for a number of years now and as such, >> an application that runs under Linux and produces sound more and more can >> be >> expected to do so using the Linux API. The only reason it _can_ be seen as >> a >> detail is due to the Just Works nature of the OSS emulation but that is >> changing due to the software mixing. Binary apps are also moving to ALSA >> currently, ie, flash, skype, ... > > If your disto ships with any OSS apps using the in-kernel emulation > you should file a bug report, as it results in bizarre and undesirable > behavior - a single app opening /dev/dsp will block audio for every > other app (OSS or ALSA) on the vast majority of hardware out there. There's software like mplayer that supports both and tries OSS first... > Lee cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Rene Herman wrote: Anyways, I suspect at least Takashi Iwai would simply say "no" to removing or deprecating the in kernel emulation anyway, although it's not likely to grow features anymore. Even if he fails to say "no" in such a case, many other people would stand up and do so :) In Linux we generally do not want to remove binary userspace interfaces. Breaking (i.e. changing) the in-kernel API is fine, but breaking the userspace ABI is quite another matter. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 6/28/07, Rene Herman <[EMAIL PROTECTED]> wrote: ALSA has been the Linux soundsystem for a number of years now and as such, an application that runs under Linux and produces sound more and more can be expected to do so using the Linux API. The only reason it _can_ be seen as a detail is due to the Just Works nature of the OSS emulation but that is changing due to the software mixing. Binary apps are also moving to ALSA currently, ie, flash, skype, ... If your disto ships with any OSS apps using the in-kernel emulation you should file a bug report, as it results in bizarre and undesirable behavior - a single app opening /dev/dsp will block audio for every other app (OSS or ALSA) on the vast majority of hardware out there. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 08:30 PM, Nix wrote: On 25 Jun 2007, Adrian Bunk stated: If people often run into this problem it might make sense to deprecate the in-kernel OSS emulation and point people to the userspace emulation instead? So now people need to know internal implementation details like if a program uses ALSA or OSS interfaces before they know how to *run* it? Point, but one that does hinge on whether or not you feel you can call using the ALSA or OSS interface an implementation detail. ALSA has been the Linux soundsystem for a number of years now and as such, an application that runs under Linux and produces sound more and more can be expected to do so using the Linux API. The only reason it _can_ be seen as a detail is due to the Just Works nature of the OSS emulation but that is changing due to the software mixing. Binary apps are also moving to ALSA currently, ie, flash, skype, ... Anyways, I suspect at least Takashi Iwai would simply say "no" to removing or deprecating the in kernel emulation anyway, although it's not likely to grow features anymore. Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 09:33 PM, Tomasz Kłoczko wrote: On 06/28/2007 06:34 PM, Anton Petrusevich wrote: Do you have an SPDIF out? If you don't then you don't need .asoundrc of course. I do on a number of cards, although being without sensible equipment (other than other soundcards) with an S/PDIF _in_ I don't actually use it for more than testing purposes. Sorry please keep all "I don't need" or "I don't count" words for themeselve. We are taking not about you but about *ALSA*. Read the next lines. And then piss off, retard troll. Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thu, 28 Jun 2007, Rene Herman wrote: On 06/28/2007 06:34 PM, Anton Petrusevich wrote: Do you have an SPDIF out? If you don't then you don't need .asoundrc of course. I do on a number of cards, although being without sensible equipment (other than other soundcards) with an S/PDIF _in_ I don't actually use it for more than testing purposes. Sorry please keep all "I don't need" or "I don't count" words for themeselve. We are taking not about you but about *ALSA*. kloczek -- --- *Ludzie nie mają problemów, tylko sobie sami je stwarzają* --- Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED]
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 06:34 PM, Anton Petrusevich wrote: Do you have an SPDIF out? If you don't then you don't need .asoundrc of course. I do on a number of cards, although being without sensible equipment (other than other soundcards) with an S/PDIF _in_ I don't actually use it for more than testing purposes. Why do I need or want an .asoundrc? What's wrong with just using the iec958 PCM device? Yes, I checked, and ICE1724 has it defined. The first thing I don't know is why you need an .asoundrc at all. Because I want to route it differently, sometimes to spdif, sometimes to headphones, These two consist of specifying different devices (iec958 and ) sometimes to mix sounds from different apps. Well, my config may be a bit ancient as it was written when dmix was not default. Right, it now is. The "default" device on your card uses both the dmix and the dsnoop (for the capture direction) plugins and if you want direct access without going through those plugins, you can select the direct "hw" devices simply by specifying them. I have read some advices for ice1724 already. The main reason I wrote to lkml -- I hate .asounrc and reading docs about it. I hate "flexebility" that requires restarting apps after changing sound routes. How would you _like_ things to work? asoundrc is a configuration file for alsa-lib. Would you perhaps suggest that alsa-lib expand its API with a snd_all_your_base_are_changed_out_from_under_you() application callback and sets notifies on its configuration file(s)? The application may have done things like enumerate the available PCM devices when it started up. Heck, maybe it's _busy_ playing through some "route" that you just changed... Is there a tool which can be used to configure .asoundrc? vi. I perfectly know this one. I would like to use some really user-friendly tool. Some would say "emacs" now, but I'll not be as childish as that. I'm not like that. At all. I am not about ice1724 or .asounrc here. I am trying to talk about user-friendliness of ALSA. It's very unfriendly. In another recent post in this thread, I linked to: http://forum.skype.com/lofiversion/index.php/t85880.html Note how it starts with: "Now that Skype uses ALSA for its sound I/O, I can set it up to work properly with my multi-channel audio interface (an Echo Gina24 with an 8-channel ADAT interface chained onto it)." That, as far as I'm concerned, says quite a bit. It says the flexibility is welcomed and used. Sure, simple things should be simple and with myself being a non-beginner-level user (user, not an audio professional) still not using or needing any configuration indicates to me that things have been partitioned correctly. Yes, I can lose my way in the configuration as well when I play with it but I expect I could actually fairly easily remedy this by learning more about it before I start. And I expect for example that you hadn't heard of the iec958 PCM device before this message so that you only _think_ stuff is complex. Generally, I tend to have some opinions on this blind insistance people seem to have they have an inalienable right to operate complex technology without turning their bloody brain on. I've been ranting just about enough now though so I'll not drag general "user friendliness" into it and just say that if I would have, it would've probably included the line "go buy a copy of windows and be gone" at some point. Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 25 Jun 2007, Adrian Bunk stated: > If people often run into this problem it might make sense to deprecate > the in-kernel OSS emulation and point people to the userspace emulation > instead? So now people need to know internal implementation details like if a program uses ALSA or OSS interfaces before they know how to *run* it? That doesn't sound especially nice to use (and before you say `distributors will do it', not all programs are built by distributors). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thu, 2007-06-28 at 18:34 +0200, Anton Petrusevich wrote: > > Please always use Reply-to-All on this list -- subscribers here like to > > also get personal copies. > > I am not subscribed to linux-kernel, I am reading it on the web. Then please subscribe just for the time you want to participate to the discussion. Xav - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thursday 28 June 2007 17:02:55 you wrote: > Please always use Reply-to-All on this list -- subscribers here like to > also get personal copies. I am not subscribed to linux-kernel, I am reading it on the web. > > I have ICE1724, a very good sound card to my taste, works like a charm. > > But with ALSA I had a really hard time to configure it properly, wanna > > see my .asoundrc? > Not particularly. I don't count as a great fan of the config file syntax > and don't use any configuration myself. Do you have an SPDIF out? If you don't then you don't need .asoundrc of course. > The first thing I don't know is why you need an .asoundrc at all. Because I want to route it differently, sometimes to spdif, sometimes to headphones, sometimes to mix sounds from different apps. Well, my config may be a bit ancient as it was written when dmix was not default. > I've CCed > the alsa-user list -- some subscribers to it probably have experience with > ice1724 and might be able to get you specific advice if you want. I have read some advices for ice1724 already. The main reason I wrote to lkml -- I hate .asounrc and reading docs about it. I hate "flexebility" that requires restarting apps after changing sound routes. > > Is there a tool which can be used to configure .asoundrc? > vi. I perfectly know this one. I would like to use some really user-friendly tool. > > > I want to be able to hear sound from flashplayer on my reciever or in my > > headphones -- how? > > Not sure? Is your receiver on an analog output and are your headphones My receiver is on spdif out. > connected directly to a card output as well? In that case, "or" would seem > to be just a mixer issue, and "and" would be dependent on hardware > abilities and needs someone who knows your specific card and setup. > > > It's not quite clear to me how to get full duplex working with my > > .asoundrc. > > It's not working without an .asoundrc? Looks like it's not working with. As skype is not so informative. > But -- I'll personally not continue this very specific subthread simply due > to not having the hardware, nor great generic experience with an .asounrc > due to not needing it myself. When I do use one, I alway start by googling > up a few examples and take it from there. Perhaps someone from alsa-user > will step in. I am not about ice1724 or .asounrc here. I am trying to talk about user-friendliness of ALSA. It's very unfriendly. -- Anton Petrusevich - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 02:42 PM, Anton Petrusevich wrote: Please always use Reply-to-All on this list -- subscribers here like to also get personal copies. I have ICE1724, a very good sound card to my taste, works like a charm. But with ALSA I had a really hard time to configure it properly, wanna see my .asoundrc? Not particularly. I don't count as a great fan of the config file syntax and don't use any configuration myself. I moreover don't own an ICE1724 card, so I'm not familiar with it's possibilities and quirks and generally, if this thread turns into guiding every user on the list through his/her respective problems with ALSA I have to respectfully decline... And I am not sure I have done it right (== the best possible way). I have read everything on http://www.alsa-project.org/documentation.php about .asoundrc. When I am using Skype I have to rename .asoundrc to something else in order to get it working. The first thing I don't know is why you need an .asoundrc at all. I've CCed the alsa-user list -- some subscribers to it probably have experience with ice1724 and might be able to get you specific advice if you want. Renaming .asoundrc seems wrong in any case. If you need anything special for Skype, it seems you could always define it in a seperate "skype" PCM and use that only from skype. When I am doing some changes to .asoundrc I have to restart the app. Yes, as far as I'm aware you do. Is there a tool which can be used to configure .asoundrc? vi. I want to be able to hear sound from flashplayer on my reciever or in my headphones -- how? Not sure? Is your receiver on an analog output and are your headphones connected directly to a card output as well? In that case, "or" would seem to be just a mixer issue, and "and" would be dependent on hardware abilities and needs someone who knows your specific card and setup. It's not quite clear to me how to get full duplex working with my .asoundrc. It's not working without an .asoundrc? But -- I'll personally not continue this very specific subthread simply due to not having the hardware, nor great generic experience with an .asounrc due to not needing it myself. When I do use one, I alway start by googling up a few examples and take it from there. Perhaps someone from alsa-user will step in. Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Our developers chose ALSA over OSS as the sound API for a VOIP-like fullduplex application and one of the reasons was API - OSS mixer API was not flexible enough (something to do with separating muting and volume control IIRC). -- Meelis Roos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Is it time for remove (crap) ALSA from kernel tree ?
>>I don't like random applications blocking my sound card. >So don't use random applications. I have ICE1724, a very good sound card to my taste, works like a charm. But with ALSA I had a really hard time to configure it properly, wanna see my .asoundrc? And I am not sure I have done it right (== the best possible way). I have read everything on http://www.alsa-project.org/documentation.php about .asoundrc. When I am using Skype I have to rename .asoundrc to something else in order to get it working. When I am doing some changes to .asoundrc I have to restart the app. Is there a tool which can be used to configure .asoundrc? I want to be able to hear sound from flashplayer on my reciever or in my headphones -- how? It's not quite clear to me how to get full duplex working with my .asoundrc. -- Anton Petrusevich - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 01:50 PM, Tomasz Kłoczko wrote: If can I join .. (again) Welcome... After upgrade to skype 1.4.x all sound output in skype I have only in left channel. Serching for skype+left+channel on google shows many people have this kind problem :> This would seem to be a (fairly, it's no doubt just outputting mono) skype specific problem and given that skype is a proprietary closed source application, you now get to go suck on a Skype support engineer! Hurrah! Or this might be helpful: http://forum.skype.com/lofiversion/index.php/t85880.html No, no idea why skype would require you to do this yourself. Maybe you should ask them. This is now _really_ no longer a kernel issue though. Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 05:04 AM, Patrick Draper wrote: Rene Herman wrote: So -- the fact that mixing actually works for you when using libaoss means software mixing is working correctly for your ALSA setup. The only thing you should do is _use_ ALSA (natively) and not its OSS emulation so you can drop the library preload. Cool. How do I go about figuring out what every app uses? For example, you mentioned that the flash 9 plugin, which I also use, is an ALSA aware application. How do you know? Various methods. If all's well, the application has a config menu where you can look at and change the settings. Or, running ldd on the binary to see if it's linked to libasound, "grep /proc//maps libasound" (also catches dlopen), "strace" or usually easiest and what I tended to do -- "lsmod" to see if starting the app triggered the automatic loading of snd-pcm-oss and snd-mixer-oss which I don't normally have loaded. This is the "[things are still not great] partly _due_ to people maintaining OSS is somehow a valid choice on Linux" that I stated early in this thread. I actually believe the kernel space OSS emulation has been fairly counter productive -- it's allowed applications to stay with an obsolete interface since the users didn't even have to _know_ due to it all just working. At least with the userspace emulation, people know they are using an OSS emulation if they are starting the application with an library preload. The kernel space emulation is a bit more bullet-proof in the sense that the userspace emulation would not for example help with applications that use direct syscalls to open device nodes and I guess that was important. When OSS/Free was replaced with ALSA inside the Linux kernel this was a big change in an area most users use and any such change inevitably opens up big cans of change resistant wankers who understand the old interface and have no need for the new one and will tell you that you did it all wrong, it was all for nothing and you suck period. They'll keep it up for years and years generally. The kernel-space OSS emulation _does_ mostly just work, which is the kind of thing that you need in this environment to be allowed to tell these people to go sexually entertain themselves. Perhaps it's now finally coming to the time where the kernel space emulation can be deprecated and eventually removed. Or not... I need the check out everything that I use which needs sound (vmware, skype, kmplayer, etc.) I don't have source code for at least two of those. I don't know if vmware by now supports native ALSA but it didn't use to. The current version of skype (1.4, still called a beta it seems) does. kmplayer seems to be a frontend for various mediaplayer solutions. Don't you just love that mess? Its backends include MPlayer and Xine, and both these can talk native ALSA fine at least. For mplayer, use a "ao=alsa" line in the .mplayer/config file (or just start it with -ao alsa) and for xine, look in its setup menu (audio tab, having set the interface level to beter than "beginner"). Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Tomasz Kłoczko wrote: On Wed, 27 Jun 2007, Patrick Draper wrote: Rene Herman wrote: So -- the fact that mixing actually works for you when using libaoss means software mixing is working correctly for your ALSA setup. The only thing you should do is _use_ ALSA (natively) and not its OSS emulation so you can drop the library preload. Cool. How do I go about figuring out what every app uses? For example, you mentioned that the flash 9 plugin, which I also use, is an ALSA aware application. How do you know? I need the check out everything that I use which needs sound (vmware, skype, kmplayer, etc.) I don't have source code for at least two of those. If can I join .. (again) Heh =) ALSA does not privide application mixer settings on application level. Some messages on skype forums suggests some workarouds in ~/.asoudrc but where is documentation for this part ? You may want to read this one: http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php Anywhere are described ALSA diagnostics procedures/technics ? kloczek Gabriel C - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Wed, 27 Jun 2007, Lee Revell wrote: On 6/26/07, Andreas Hartmetz <[EMAIL PROTECTED]> wrote: Why not put the whole sound system in userland? It has been done before. Sound is just not performance critical at all and it's almost never mission critical. There are dozens of companies selling Linux powered professional audio gear, multiple pro audio centric distros, and hundreds of serious free software audio apps. I suspect these developers and their users would disagree. OK .. hundreds. Can you list ten ? Can you point to oppinions of this people about ALSA ? kloczek -- --- *Ludzie nie mają problemów, tylko sobie sami je stwarzają* --- Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED]
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Wed, 27 Jun 2007, Patrick Draper wrote: Rene Herman wrote: So -- the fact that mixing actually works for you when using libaoss means software mixing is working correctly for your ALSA setup. The only thing you should do is _use_ ALSA (natively) and not its OSS emulation so you can drop the library preload. Cool. How do I go about figuring out what every app uses? For example, you mentioned that the flash 9 plugin, which I also use, is an ALSA aware application. How do you know? I need the check out everything that I use which needs sound (vmware, skype, kmplayer, etc.) I don't have source code for at least two of those. If can I join .. (again) After upgrade to skype 1.4.x all sound output in skype I have only in left channel. Serching for skype+left+channel on google shows many people have this kind problem :> ALSA does not privide application mixer settings on application level. Some messages on skype forums suggests some workarouds in ~/.asoudrc but where is documentation for this part ? Anywhere are described ALSA diagnostics procedures/technics ? kloczek -- --- *Ludzie nie mają problemów, tylko sobie sami je stwarzają* --- Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED]
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 04:28 AM, Rene Herman wrote: On 06/28/2007 03:58 AM, Rene Herman wrote: to figure it out. If you need to specify an ALSA device somewhere, make sure it's not the old "hw:0" but "default" (or "default:0" for the first card, "default:1" for the second, ...). The "hw:N" devices don't do mixing. Slight correction/expansion -- don't do _software_ mixing. Some cards can do hardware mixing and in that case, "hw:N" or, specifically "hw:N,0", "hw:N,1" and so on devices are available as hardware mixed devices. Correcting the correction (sorry, it was late) -- "hw:N" is card N, "hw:N,M" is PCM interface M of card N and "hw:N,M,K" is (hardware mixed) subdevice K on PCM interface M of card N. Normal cards have only one PCM interface meaning that M is 0 in the above. That is, I meant that "hw:N,0,0", "hw:N,0,1" and so on are the hardware mixed devices. Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 04:28 AM, Rene Herman wrote: On 06/28/2007 03:58 AM, Rene Herman wrote: to figure it out. If you need to specify an ALSA device somewhere, make sure it's not the old hw:0 but default (or default:0 for the first card, default:1 for the second, ...). The hw:N devices don't do mixing. Slight correction/expansion -- don't do _software_ mixing. Some cards can do hardware mixing and in that case, hw:N or, specifically hw:N,0, hw:N,1 and so on devices are available as hardware mixed devices. Correcting the correction (sorry, it was late) -- hw:N is card N, hw:N,M is PCM interface M of card N and hw:N,M,K is (hardware mixed) subdevice K on PCM interface M of card N. Normal cards have only one PCM interface meaning that M is 0 in the above. That is, I meant that hw:N,0,0, hw:N,0,1 and so on are the hardware mixed devices. Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Wed, 27 Jun 2007, Patrick Draper wrote: Rene Herman wrote: So -- the fact that mixing actually works for you when using libaoss means software mixing is working correctly for your ALSA setup. The only thing you should do is _use_ ALSA (natively) and not its OSS emulation so you can drop the library preload. Cool. How do I go about figuring out what every app uses? For example, you mentioned that the flash 9 plugin, which I also use, is an ALSA aware application. How do you know? I need the check out everything that I use which needs sound (vmware, skype, kmplayer, etc.) I don't have source code for at least two of those. If can I join .. (again) After upgrade to skype 1.4.x all sound output in skype I have only in left channel. Serching for skype+left+channel on google shows many people have this kind problem : ALSA does not privide application mixer settings on application level. Some messages on skype forums suggests some workarouds in ~/.asoudrc but where is documentation for this part ? Anywhere are described ALSA diagnostics procedures/technics ? kloczek -- --- *Ludzie nie mają problemów, tylko sobie sami je stwarzają* --- Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED]
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Wed, 27 Jun 2007, Lee Revell wrote: On 6/26/07, Andreas Hartmetz [EMAIL PROTECTED] wrote: Why not put the whole sound system in userland? It has been done before. Sound is just not performance critical at all and it's almost never mission critical. There are dozens of companies selling Linux powered professional audio gear, multiple pro audio centric distros, and hundreds of serious free software audio apps. I suspect these developers and their users would disagree. OK .. hundreds. Can you list ten ? Can you point to oppinions of this people about ALSA ? kloczek -- --- *Ludzie nie mają problemów, tylko sobie sami je stwarzają* --- Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED]
Re: Is it time for remove (crap) ALSA from kernel tree ?
Tomasz Kłoczko wrote: On Wed, 27 Jun 2007, Patrick Draper wrote: Rene Herman wrote: So -- the fact that mixing actually works for you when using libaoss means software mixing is working correctly for your ALSA setup. The only thing you should do is _use_ ALSA (natively) and not its OSS emulation so you can drop the library preload. Cool. How do I go about figuring out what every app uses? For example, you mentioned that the flash 9 plugin, which I also use, is an ALSA aware application. How do you know? I need the check out everything that I use which needs sound (vmware, skype, kmplayer, etc.) I don't have source code for at least two of those. If can I join .. (again) Heh =) ALSA does not privide application mixer settings on application level. Some messages on skype forums suggests some workarouds in ~/.asoudrc but where is documentation for this part ? You may want to read this one: http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php Anywhere are described ALSA diagnostics procedures/technics ? kloczek Gabriel C - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 05:04 AM, Patrick Draper wrote: Rene Herman wrote: So -- the fact that mixing actually works for you when using libaoss means software mixing is working correctly for your ALSA setup. The only thing you should do is _use_ ALSA (natively) and not its OSS emulation so you can drop the library preload. Cool. How do I go about figuring out what every app uses? For example, you mentioned that the flash 9 plugin, which I also use, is an ALSA aware application. How do you know? Various methods. If all's well, the application has a config menu where you can look at and change the settings. Or, running ldd on the binary to see if it's linked to libasound, grep /proc/pid/maps libasound (also catches dlopen), strace or usually easiest and what I tended to do -- lsmod to see if starting the app triggered the automatic loading of snd-pcm-oss and snd-mixer-oss which I don't normally have loaded. This is the [things are still not great] partly _due_ to people maintaining OSS is somehow a valid choice on Linux that I stated early in this thread. I actually believe the kernel space OSS emulation has been fairly counter productive -- it's allowed applications to stay with an obsolete interface since the users didn't even have to _know_ due to it all just working. At least with the userspace emulation, people know they are using an OSS emulation if they are starting the application with an library preload. The kernel space emulation is a bit more bullet-proof in the sense that the userspace emulation would not for example help with applications that use direct syscalls to open device nodes and I guess that was important. When OSS/Free was replaced with ALSA inside the Linux kernel this was a big change in an area most users use and any such change inevitably opens up big cans of change resistant wankers who understand the old interface and have no need for the new one and will tell you that you did it all wrong, it was all for nothing and you suck period. They'll keep it up for years and years generally. The kernel-space OSS emulation _does_ mostly just work, which is the kind of thing that you need in this environment to be allowed to tell these people to go sexually entertain themselves. Perhaps it's now finally coming to the time where the kernel space emulation can be deprecated and eventually removed. Or not... I need the check out everything that I use which needs sound (vmware, skype, kmplayer, etc.) I don't have source code for at least two of those. I don't know if vmware by now supports native ALSA but it didn't use to. The current version of skype (1.4, still called a beta it seems) does. kmplayer seems to be a frontend for various mediaplayer solutions. Don't you just love that mess? Its backends include MPlayer and Xine, and both these can talk native ALSA fine at least. For mplayer, use a ao=alsa line in the .mplayer/config file (or just start it with -ao alsa) and for xine, look in its setup menu (audio tab, having set the interface level to beter than beginner). Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 01:50 PM, Tomasz Kłoczko wrote: If can I join .. (again) Welcome... After upgrade to skype 1.4.x all sound output in skype I have only in left channel. Serching for skype+left+channel on google shows many people have this kind problem : This would seem to be a (fairly, it's no doubt just outputting mono) skype specific problem and given that skype is a proprietary closed source application, you now get to go suck on a Skype support engineer! Hurrah! Or this might be helpful: http://forum.skype.com/lofiversion/index.php/t85880.html No, no idea why skype would require you to do this yourself. Maybe you should ask them. This is now _really_ no longer a kernel issue though. Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Is it time for remove (crap) ALSA from kernel tree ?
I don't like random applications blocking my sound card. So don't use random applications. I have ICE1724, a very good sound card to my taste, works like a charm. But with ALSA I had a really hard time to configure it properly, wanna see my .asoundrc? And I am not sure I have done it right (== the best possible way). I have read everything on http://www.alsa-project.org/documentation.php about .asoundrc. When I am using Skype I have to rename .asoundrc to something else in order to get it working. When I am doing some changes to .asoundrc I have to restart the app. Is there a tool which can be used to configure .asoundrc? I want to be able to hear sound from flashplayer on my reciever or in my headphones -- how? It's not quite clear to me how to get full duplex working with my .asoundrc. -- Anton Petrusevich - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Our developers chose ALSA over OSS as the sound API for a VOIP-like fullduplex application and one of the reasons was API - OSS mixer API was not flexible enough (something to do with separating muting and volume control IIRC). -- Meelis Roos - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 02:42 PM, Anton Petrusevich wrote: Please always use Reply-to-All on this list -- subscribers here like to also get personal copies. I have ICE1724, a very good sound card to my taste, works like a charm. But with ALSA I had a really hard time to configure it properly, wanna see my .asoundrc? Not particularly. I don't count as a great fan of the config file syntax and don't use any configuration myself. I moreover don't own an ICE1724 card, so I'm not familiar with it's possibilities and quirks and generally, if this thread turns into guiding every user on the list through his/her respective problems with ALSA I have to respectfully decline... And I am not sure I have done it right (== the best possible way). I have read everything on http://www.alsa-project.org/documentation.php about .asoundrc. When I am using Skype I have to rename .asoundrc to something else in order to get it working. The first thing I don't know is why you need an .asoundrc at all. I've CCed the alsa-user list -- some subscribers to it probably have experience with ice1724 and might be able to get you specific advice if you want. Renaming .asoundrc seems wrong in any case. If you need anything special for Skype, it seems you could always define it in a seperate skype PCM and use that only from skype. When I am doing some changes to .asoundrc I have to restart the app. Yes, as far as I'm aware you do. Is there a tool which can be used to configure .asoundrc? vi. I want to be able to hear sound from flashplayer on my reciever or in my headphones -- how? Not sure? Is your receiver on an analog output and are your headphones connected directly to a card output as well? In that case, or would seem to be just a mixer issue, and and would be dependent on hardware abilities and needs someone who knows your specific card and setup. It's not quite clear to me how to get full duplex working with my .asoundrc. It's not working without an .asoundrc? But -- I'll personally not continue this very specific subthread simply due to not having the hardware, nor great generic experience with an .asounrc due to not needing it myself. When I do use one, I alway start by googling up a few examples and take it from there. Perhaps someone from alsa-user will step in. Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thursday 28 June 2007 17:02:55 you wrote: Please always use Reply-to-All on this list -- subscribers here like to also get personal copies. I am not subscribed to linux-kernel, I am reading it on the web. I have ICE1724, a very good sound card to my taste, works like a charm. But with ALSA I had a really hard time to configure it properly, wanna see my .asoundrc? Not particularly. I don't count as a great fan of the config file syntax and don't use any configuration myself. Do you have an SPDIF out? If you don't then you don't need .asoundrc of course. The first thing I don't know is why you need an .asoundrc at all. Because I want to route it differently, sometimes to spdif, sometimes to headphones, sometimes to mix sounds from different apps. Well, my config may be a bit ancient as it was written when dmix was not default. I've CCed the alsa-user list -- some subscribers to it probably have experience with ice1724 and might be able to get you specific advice if you want. I have read some advices for ice1724 already. The main reason I wrote to lkml -- I hate .asounrc and reading docs about it. I hate flexebility that requires restarting apps after changing sound routes. Is there a tool which can be used to configure .asoundrc? vi. I perfectly know this one. I would like to use some really user-friendly tool. I want to be able to hear sound from flashplayer on my reciever or in my headphones -- how? Not sure? Is your receiver on an analog output and are your headphones My receiver is on spdif out. connected directly to a card output as well? In that case, or would seem to be just a mixer issue, and and would be dependent on hardware abilities and needs someone who knows your specific card and setup. It's not quite clear to me how to get full duplex working with my .asoundrc. It's not working without an .asoundrc? Looks like it's not working with. As skype is not so informative. But -- I'll personally not continue this very specific subthread simply due to not having the hardware, nor great generic experience with an .asounrc due to not needing it myself. When I do use one, I alway start by googling up a few examples and take it from there. Perhaps someone from alsa-user will step in. I am not about ice1724 or .asounrc here. I am trying to talk about user-friendliness of ALSA. It's very unfriendly. -- Anton Petrusevich - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thu, 2007-06-28 at 18:34 +0200, Anton Petrusevich wrote: Please always use Reply-to-All on this list -- subscribers here like to also get personal copies. I am not subscribed to linux-kernel, I am reading it on the web. Then please subscribe just for the time you want to participate to the discussion. Xav - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 25 Jun 2007, Adrian Bunk stated: If people often run into this problem it might make sense to deprecate the in-kernel OSS emulation and point people to the userspace emulation instead? So now people need to know internal implementation details like if a program uses ALSA or OSS interfaces before they know how to *run* it? That doesn't sound especially nice to use (and before you say `distributors will do it', not all programs are built by distributors). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 06:34 PM, Anton Petrusevich wrote: Do you have an SPDIF out? If you don't then you don't need .asoundrc of course. I do on a number of cards, although being without sensible equipment (other than other soundcards) with an S/PDIF _in_ I don't actually use it for more than testing purposes. Why do I need or want an .asoundrc? What's wrong with just using the iec958 PCM device? Yes, I checked, and ICE1724 has it defined. The first thing I don't know is why you need an .asoundrc at all. Because I want to route it differently, sometimes to spdif, sometimes to headphones, These two consist of specifying different devices (iec958 and see below) sometimes to mix sounds from different apps. Well, my config may be a bit ancient as it was written when dmix was not default. Right, it now is. The default device on your card uses both the dmix and the dsnoop (for the capture direction) plugins and if you want direct access without going through those plugins, you can select the direct hw devices simply by specifying them. I have read some advices for ice1724 already. The main reason I wrote to lkml -- I hate .asounrc and reading docs about it. I hate flexebility that requires restarting apps after changing sound routes. How would you _like_ things to work? asoundrc is a configuration file for alsa-lib. Would you perhaps suggest that alsa-lib expand its API with a snd_all_your_base_are_changed_out_from_under_you() application callback and sets notifies on its configuration file(s)? The application may have done things like enumerate the available PCM devices when it started up. Heck, maybe it's _busy_ playing through some route that you just changed... Is there a tool which can be used to configure .asoundrc? vi. I perfectly know this one. I would like to use some really user-friendly tool. Some would say emacs now, but I'll not be as childish as that. I'm not like that. At all. I am not about ice1724 or .asounrc here. I am trying to talk about user-friendliness of ALSA. It's very unfriendly. In another recent post in this thread, I linked to: http://forum.skype.com/lofiversion/index.php/t85880.html Note how it starts with: Now that Skype uses ALSA for its sound I/O, I can set it up to work properly with my multi-channel audio interface (an Echo Gina24 with an 8-channel ADAT interface chained onto it). That, as far as I'm concerned, says quite a bit. It says the flexibility is welcomed and used. Sure, simple things should be simple and with myself being a non-beginner-level user (user, not an audio professional) still not using or needing any configuration indicates to me that things have been partitioned correctly. Yes, I can lose my way in the configuration as well when I play with it but I expect I could actually fairly easily remedy this by learning more about it before I start. And I expect for example that you hadn't heard of the iec958 PCM device before this message so that you only _think_ stuff is complex. Generally, I tend to have some opinions on this blind insistance people seem to have they have an inalienable right to operate complex technology without turning their bloody brain on. I've been ranting just about enough now though so I'll not drag general user friendliness into it and just say that if I would have, it would've probably included the line go buy a copy of windows and be gone at some point. Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thu, 28 Jun 2007, Rene Herman wrote: On 06/28/2007 06:34 PM, Anton Petrusevich wrote: Do you have an SPDIF out? If you don't then you don't need .asoundrc of course. I do on a number of cards, although being without sensible equipment (other than other soundcards) with an S/PDIF _in_ I don't actually use it for more than testing purposes. Sorry please keep all I don't need or I don't count words for themeselve. We are taking not about you but about *ALSA*. kloczek -- --- *Ludzie nie mają problemów, tylko sobie sami je stwarzają* --- Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED]
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 09:33 PM, Tomasz Kłoczko wrote: On 06/28/2007 06:34 PM, Anton Petrusevich wrote: Do you have an SPDIF out? If you don't then you don't need .asoundrc of course. I do on a number of cards, although being without sensible equipment (other than other soundcards) with an S/PDIF _in_ I don't actually use it for more than testing purposes. Sorry please keep all I don't need or I don't count words for themeselve. We are taking not about you but about *ALSA*. Read the next lines. And then piss off, retard troll. Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 08:30 PM, Nix wrote: On 25 Jun 2007, Adrian Bunk stated: If people often run into this problem it might make sense to deprecate the in-kernel OSS emulation and point people to the userspace emulation instead? So now people need to know internal implementation details like if a program uses ALSA or OSS interfaces before they know how to *run* it? Point, but one that does hinge on whether or not you feel you can call using the ALSA or OSS interface an implementation detail. ALSA has been the Linux soundsystem for a number of years now and as such, an application that runs under Linux and produces sound more and more can be expected to do so using the Linux API. The only reason it _can_ be seen as a detail is due to the Just Works nature of the OSS emulation but that is changing due to the software mixing. Binary apps are also moving to ALSA currently, ie, flash, skype, ... Anyways, I suspect at least Takashi Iwai would simply say no to removing or deprecating the in kernel emulation anyway, although it's not likely to grow features anymore. Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 6/28/07, Rene Herman [EMAIL PROTECTED] wrote: ALSA has been the Linux soundsystem for a number of years now and as such, an application that runs under Linux and produces sound more and more can be expected to do so using the Linux API. The only reason it _can_ be seen as a detail is due to the Just Works nature of the OSS emulation but that is changing due to the software mixing. Binary apps are also moving to ALSA currently, ie, flash, skype, ... If your disto ships with any OSS apps using the in-kernel emulation you should file a bug report, as it results in bizarre and undesirable behavior - a single app opening /dev/dsp will block audio for every other app (OSS or ALSA) on the vast majority of hardware out there. Lee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Rene Herman wrote: Anyways, I suspect at least Takashi Iwai would simply say no to removing or deprecating the in kernel emulation anyway, although it's not likely to grow features anymore. Even if he fails to say no in such a case, many other people would stand up and do so :) In Linux we generally do not want to remove binary userspace interfaces. Breaking (i.e. changing) the in-kernel API is fine, but breaking the userspace ABI is quite another matter. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thu, Jun 28, 2007 at 04:20:45PM -0400, Lee Revell wrote: On 6/28/07, Rene Herman [EMAIL PROTECTED] wrote: ALSA has been the Linux soundsystem for a number of years now and as such, an application that runs under Linux and produces sound more and more can be expected to do so using the Linux API. The only reason it _can_ be seen as a detail is due to the Just Works nature of the OSS emulation but that is changing due to the software mixing. Binary apps are also moving to ALSA currently, ie, flash, skype, ... If your disto ships with any OSS apps using the in-kernel emulation you should file a bug report, as it results in bizarre and undesirable behavior - a single app opening /dev/dsp will block audio for every other app (OSS or ALSA) on the vast majority of hardware out there. There's software like mplayer that supports both and tries OSS first... Lee cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thu, Jun 28, 2007 at 07:30:36PM +0100, Nix wrote: On 25 Jun 2007, Adrian Bunk stated: If people often run into this problem it might make sense to deprecate the in-kernel OSS emulation and point people to the userspace emulation instead? So now people need to know internal implementation details like if a program uses ALSA or OSS interfaces before they know how to *run* it? That doesn't sound especially nice to use (and before you say `distributors will do it', not all programs are built by distributors). The interesting point is that what you call internal implementation details is much _more_ exposed with the OSS emulation in the kernel _enabled_. Why? Linux software not supporting ALSA has becoming quite esoteric. But software like mplayer supporting both and trying OSS first and software supporting both and letting the user choose is today much more common. And that's exactly the case where users run into the results of the internal implementation detail that their application used the in-kernel OSS emulation instead of ALSA resulting in exactly these problems. There is also a userspace OSS emulation for ALSA not suffering from these problems. It's not my decision whether or not to remove the in-kernel OSS emulation, all I'm saying is that removing it might actually result in less users having problems. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 11:06 PM, Adrian Bunk wrote: The interesting point is that what you call internal implementation details is much _more_ exposed with the OSS emulation in the kernel _enabled_. Why? Linux software not supporting ALSA has becoming quite esoteric. But software like mplayer supporting both and trying OSS first and software supporting both and letting the user choose is today much more common. And that's exactly the case where users run into the results of the internal implementation detail that their application used the in-kernel OSS emulation instead of ALSA resulting in exactly these problems. There is also a userspace OSS emulation for ALSA not suffering from these problems. It's not my decision whether or not to remove the in-kernel OSS emulation, all I'm saying is that removing it might actually result in less users having problems. For what it's worth -- I do agree with this... Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 28 Jun 2007, Adrian Bunk outgrape: Linux software not supporting ALSA has becoming quite esoteric. Indeed. This is why I haven't moaned much (or at all): aoss is ugly, sure, but you only need it for those rare apps which run for a long time or while other sounds are playing, on non-mixing-capable hardware, for which the in-kernel emulation won't suit... and most non-sound- specialist apps are using esd, arts or pulseaudio anyway, so that does the mixing for you (and pulseaudio also does it for every ALSA app if the pulseaudio plugin is installed). And the sound-specialist apps are the ones that actually *benefit* from ALSA's ludicrous degree of low-levelness, so they're using it, or something even more flexible like JACK. I use quite a lot of sound apps, and I can count the number of times I've had to use aoss in the last year on the fingers of one hand. But still it's conceptually ugly. Doing stuff in userspace, yes: but the kernel should be calling *back* to userspace to do it, not depending on things being done in the client's address space by a client library for proper function. (See also others' rants regarding the nasty quasi-unstable nature of the ALSA ioctl() kernel interface...) Isn't this sort of big user-to-and-from-kernelspace data-transfer job what we have relayfs for? (Or is it unidirectional?) common. And that's exactly the case where users run into the results of the internal implementation detail that their application used the in-kernel OSS emulation instead of ALSA resulting in exactly these problems. There is also a userspace OSS emulation for ALSA not suffering from these problems. The problem is that the user has to *know* to run `aoss'. The in-kernel OSS emulation is actually nicer than thr userspace one because it works automatically without the user having to do a damned thing. If only it (and ALSA as a whole) called out to userspace again to mix, we could presumably ditch aoss, and the user would never need to care which API the author chose to use. (There are still complexities involving reading the user's .asoundrc to consider, but most users don't use that so wouldn't need aoss for anything anymore.) And then all these damn silly ALSA/OSS flamewars could go away. It's not my decision whether or not to remove the in-kernel OSS emulation, all I'm saying is that removing it might actually result in less users having problems. I think it would lead to *more* problems. The in-kernel emulation *almost* Just Works, and surely the ideal we should aim for is an emulation that Just Works. -- `... in the sense that dragons logically follow evolution so they would be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep furiously - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Anton Petrusevich wrote: On Thursday 28 June 2007 17:02:55 you wrote: Please always use Reply-to-All on this list -- subscribers here like to also get personal copies. I am not subscribed to linux-kernel, I am reading it on the web. I have ICE1724, a very good sound card to my taste, works like a charm. But with ALSA I had a really hard time to configure it properly, wanna see my .asoundrc? Not particularly. I don't count as a great fan of the config file syntax and don't use any configuration myself. Do you have an SPDIF out? If you don't then you don't need .asoundrc of course. The first thing I don't know is why you need an .asoundrc at all. Because I want to route it differently, sometimes to spdif, sometimes to headphones, sometimes to mix sounds from different apps. Well, my config may be a bit ancient as it was written when dmix was not default. I've CCed the alsa-user list -- some subscribers to it probably have experience with ice1724 and might be able to get you specific advice if you want. I have read some advices for ice1724 already. The main reason I wrote to lkml -- I hate .asounrc and reading docs about it. I hate flexebility that requires restarting apps after changing sound routes. Is there a tool which can be used to configure .asoundrc? vi. I perfectly know this one. I would like to use some really user-friendly tool. I want to be able to hear sound from flashplayer on my reciever or in my headphones -- how? Not sure? Is your receiver on an analog output and are your headphones My receiver is on spdif out. connected directly to a card output as well? In that case, or would seem to be just a mixer issue, and and would be dependent on hardware abilities and needs someone who knows your specific card and setup. It's not quite clear to me how to get full duplex working with my .asoundrc. It's not working without an .asoundrc? Looks like it's not working with. As skype is not so informative. But -- I'll personally not continue this very specific subthread simply due to not having the hardware, nor great generic experience with an .asounrc due to not needing it myself. When I do use one, I alway start by googling up a few examples and take it from there. Perhaps someone from alsa-user will step in. I am not about ice1724 or .asounrc here. I am trying to talk about user-friendliness of ALSA. It's very unfriendly. In the case of S/PDIF output on ice1724 (and probably other cards), it would be nice if ALSA defaulted to routing default audio to both the S/PDIF and analog ports, as this is what most users would normally expect.. The Windows drivers work like that, but on Linux you have to pick one or the other (at least without a bunch of mucking with the config file). -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Wed, 2007-06-27 at 22:04 -0500, Patrick Draper wrote: > Rene Herman wrote: > > So -- the fact that mixing actually works for you when using libaoss > > means software mixing is working correctly for your ALSA setup. The only > > thing you should do is _use_ ALSA (natively) and not its OSS emulation > > so you can drop the library preload. > > Cool. How do I go about figuring out what every app uses? For example, > you mentioned that the flash 9 plugin, which I also use, is an ALSA > aware application. How do you know? I need the check out everything that > I use which needs sound (vmware, skype, kmplayer, etc.) I don't have > source code for at least two of those. run ldd on the binary... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 6/26/07, Andreas Hartmetz <[EMAIL PROTECTED]> wrote: Why not put the whole sound system in userland? It has been done before. Sound is just not performance critical at all and it's almost never mission critical. There are dozens of companies selling Linux powered professional audio gear, multiple pro audio centric distros, and hundreds of serious free software audio apps. I suspect these developers and their users would disagree. I agree with you about userland drivers but at minimum this would require merging the -rt kernel patches, otherwise the latency/jitter will be too high to do anything but toy desktop sounds, then you need a mergeable mechanism for doing DMA and interrupt handling in userspace. It has been attempted before but never evolved to the point where you could drive a complex device like the emu10k1. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 6/27/07, Patrick Draper <[EMAIL PROTECTED]> wrote: Rene Herman wrote: > So -- the fact that mixing actually works for you when using libaoss > means software mixing is working correctly for your ALSA setup. The only > thing you should do is _use_ ALSA (natively) and not its OSS emulation > so you can drop the library preload. Cool. How do I go about figuring out what every app uses? For example, you mentioned that the flash 9 plugin, which I also use, is an ALSA aware application. How do you know? I need the check out everything that I use which needs sound (vmware, skype, kmplayer, etc.) I don't have source code for at least two of those. Go into the sound preferences menu of the app and check which device it uses. If it's something like /dev/dsp or /dev/audio it's using OSS. If it looks like "default" or "hw:0" it's ALSA. If your app does not have any sound preferences menu it's broken and you should file a bug report. You can determine whether an app with no configurable sound device is using ALSA by running "strace broken_app" and grep the output for "/dev/dsp" or "/dev/audio". Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Rene Herman wrote: So -- the fact that mixing actually works for you when using libaoss means software mixing is working correctly for your ALSA setup. The only thing you should do is _use_ ALSA (natively) and not its OSS emulation so you can drop the library preload. Cool. How do I go about figuring out what every app uses? For example, you mentioned that the flash 9 plugin, which I also use, is an ALSA aware application. How do you know? I need the check out everything that I use which needs sound (vmware, skype, kmplayer, etc.) I don't have source code for at least two of those. Thanks, Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 03:58 AM, Rene Herman wrote: to figure it out. If you need to specify an ALSA device somewhere, make sure it's not the old "hw:0" but "default" (or "default:0" for the first card, "default:1" for the second, ...). The "hw:N" devices don't do mixing. Slight correction/expansion -- don't do _software_ mixing. Some cards can do hardware mixing and in that case, "hw:N" or, specifically "hw:N,0", "hw:N,1" and so on devices are available as hardware mixed devices. Try a cat /proc/asound/card0/pcm0p/info and check the "subdevices_count" for the number of hardware mixed playback devices you have available. If it's 1, your card should've been configured (by ALSA itself) to use software mixing by default and if it's higher than 1, it should not have been and will use hardware mixing... Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/28/2007 02:18 AM, Patrick Draper wrote: Please always use Reply-to-All on this list -- subscribers here like to also get personal copies. Rene Herman wrote: KDE has finally dropped aRts from KDE4 and, again, ALSA has been mixing by default for some time now so we're talking history anyway. You want mixing on your card? You got it. I've been following this discussion with some interest, to learn more about ALSA. I've been creating startup scripts for all of my sound-using applications which look like this: LD_PRELOAD=libaoss.so exec /usr/bin/alsaplayer "$*" I found that without libaoss.so preloaded, I wasn't getting software mixing at all. This would seem to indicate that your alsaplayer (what's in a name) is setup to output to OSS and not to ALSA... The OSS interface -- consisting of direct access to device nodes such as /dev/dsp0, /dev/mixer and /dev/music -- is an older interface for sound on Linux. The newer ALSA interface works via a library API and is best used natively. For backwards compatibility though, ALSA also provides emulation of the older OSS interface. It does so in two different ways in fact -- the first one is a direct kernel space emulation where ALSA interprets accesses to those device nodes it then manages much like real OSS would do. This kernel space emulation is made available through the "OSS PCM/Mixer/Sequencer API" you see as options in the ALSA kernel configuration menu. The other way is a userspace emulation through the libaoss.so library that you are using. That library catches accesses to the OSS device nodes in userspace and translates them to ALSA accesses before they even get to the kernel. ALSA does software mixing (the act of mixing two seperate streams together to form one) in userspace and as such, the kernelspace OSS emulation does not support software mixing, while this userspace emulation does -- if your ALSA default device is setup for software mixing (it is by default these days) this also works for this libaoss route. If you run a OSS program without the library preload it's using the kernel emulation though. So -- the fact that mixing actually works for you when using libaoss means software mixing is working correctly for your ALSA setup. The only thing you should do is _use_ ALSA (natively) and not its OSS emulation so you can drop the library preload. I don't have alsaplayer installed (wasn't that thing dead?) so I can't walk you through its configuration easily, but I suppose you'll be able to figure it out. If you need to specify an ALSA device somewhere, make sure it's not the old "hw:0" but "default" (or "default:0" for the first card, "default:1" for the second, ...). The "hw:N" devices don't do mixing. I'm constantly running an MP3 player, and with that library I can get sound alerts from other apps too. I myself mostly use the ogg123 and mpg321 command line players, both based on libao and thereby only a simple: $ echo "default_driver=alsa09" >/etc/libao.conf away from being native ALSA players. I don't understand exactly what you mean by ALSA mixing by default. I have the OSS Mixer API selected during kernel compiles. Is that what you are referring to? No. That's part of the kernel space OSS emulation. A "mixer" in that context is the part of a soundcard that controls volumes and may mix the output of several parts of the card/chip for playback and its inputs for capture. Ie, that which is controlled by a mixer application such as the (ncurses) ALSA reference mixer "alsamixer" or the mixer your desktop environment provides. Once you have everything running as a native ALSA application you could disable that option. In fact, since you're using the userspace emulation, you could already. The new-ish Flash Player 9 (important for youtube these days) for Linux is also an ALSA application and since I use it, I myself haven't needed OSS emulation for anything anymore. Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Rene Herman wrote: KDE has finally dropped aRts from KDE4 and, again, ALSA has been mixing by default for some time now so we're talking history anyway. You want mixing on your card? You got it. I've been following this discussion with some interest, to learn more about ALSA. I've been creating startup scripts for all of my sound-using applications which look like this: LD_PRELOAD=libaoss.so exec /usr/bin/alsaplayer "$*" I found that without libaoss.so preloaded, I wasn't getting software mixing at all. I'm constantly running an MP3 player, and with that library I can get sound alerts from other apps too. I don't understand exactly what you mean by ALSA mixing by default. I have the OSS Mixer API selected during kernel compiles. Is that what you are referring to? Thanks, Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/27/2007 09:10 PM, Andreas Hartmetz wrote: I don't like random applications blocking my sound card. So don't use random applications. I imitated the style of the mail I replied to. Besides, choosing apps based on sound system is retarded if you wanted to indicate that this should be done more often or something. What I indicated was that if someone wants to use multiple applications that work together bringing you The One Integrated Sound Experience it might make sense to use applications... that work together. Don't go blame ALSA for either the fact that aRTs isn't actually useful nor KDE's decision to stick with it for way too long. See -- the problem is again not ALSA (or OSS for that matter) but userspace not getting its act together. KDE has finally dropped aRts from KDE4 and, again, ALSA has been mixing by default for some time now so we're talking history anyway. You want mixing on your card? You got it. Many don't -- they might not care about desktop sounds period and/or they might use a clumsy chip/card for that and use a nice one for music without any need for mixing on it (such as I do). Admittedly, mixing Abba's Dancing Queen with Slayer's Angel of Death is great fun for quite a while but at some point you do actually grow weary of it... Exactly! And the config file is hostile if you want to change it. It could be a bit nicer yes. Since software mixing is enabled by default now no configuration is generally needed though and it seems not a particularly huge priority. Now that it's an advanced feature, maybe the flexibility pays off in fact -- not sure, I don't use any configuration myself other than for some testing and playing around every once in a while. KDE 2 *was* released in 2000. Why would you care, I already admitted that sound daemons were there before ALSA. Because blaming ALSA for bad decisions made by others seems a little off and you did exactly that a few messages back. Not nice! You give up reporting small hardware problems that bother you because the application developer documentation for something is not in great shape? Yep, because I was frustrated with the whole thing. Having huge bad APIs with no documentation is telling your fellow developers to piss off and do something else. I did. You weren't having a developer problem but a user problem. Your problem was not with the API documentation but with what would appear to be a simple glitch in one particular driver. Mixing that in with a "ALSA sucks because its documentation isn't upto par" is a little disingenious. Sure the (library) documentation blows donkeys. So wat else's is new in the land of Linux? I recently did a block-ish driver. Documentation? Whahahaha! So that leaves that "bad" that you prefixed API with but keep in mind that ALSA is designed as an audio system suitable for advanced/professional use while also still filling the needs of consumer users and that it does in fact do so is obvious from the fact that everyone's using it. A complex API is the downside of flexibility. Perhaps it would've been better if alsa-lib had also made a very simple API available to non-demanding users from the start but other software can do that as well. For my current purposes libao does, but I hope in the future something like Phonon does. The ideal situation is that anyone in userspace is using a single API _such_ as Phonon since userspace has to synchronise things itself as well -- it might for example want to provide you with the option to automatically mute your music when you get an incoming call and this is not something which alsa-lib can do by itself. If it looks like I'm shifting blame -- you bet I am. It's userspace which has for years failed to get its multimedia act together, with KDE and GNOME going out of their way to pick other infrastructure than the other one. The kernel is not a guilty party and improvements should be sought where the problems lie. As said earlier, KDE4 might just be such an improvement. Personally I'm hoping I'll even manage to start running it this time because damnit, I miss solitaire... hacking (i.e. more features faster). Latency is an issue? - Well you can't play sound without userspace creating it so you're not adding any new problems. Capture. If you are not doing DMA from the sound card to kernel memory and then directly to disk blocks, you are using user space apps period. So what's different with capture? The latency in this case is defined as the time between data arriving at the machine from the outside and it being available for further processing by an application. Think looping stuff out again in realtime after doing something to it to see why you want it to be low. If you'll grant that all those users who were dissatisfied with early 2.6 weren't just blowing smoke, I assume you'll grant that latency matters and that putting it all in userspace is not an obvious step in minimising
Re: Is it time for remove (crap) ALSA from kernel tree ?
> > I don't like random applications blocking my sound card. > > So don't use random applications. > I imitated the style of the mail I replied to. Besides, choosing apps based on sound system is retarded if you wanted to indicate that this should be done more often or something. > > You are concerned about your precious audio quality? Me too. Most people, > > however, are using god-awful plastic speakers for twenty euros and shitty > > onboard sound chips. Sad but true. > > Exactly, which is why mixing has been default for some time now for most > cards. Are you only ranting about how it should've been earlier? > Exactly! And the config file is hostile if you want to change it. > > ALSA appeared in 1999, KDE 2 with aRtsd (another catastrophic failure of > > technology) was released in october 2000. > > http://www.arts-project.org/gen/newsarchive/news_1998.html > KDE 2 *was* released in 2000. Why would you care, I already admitted that sound daemons were there before ALSA. > >> That sounds like a minor glitch that should be easily remedied if you > >> file a proper bug report. Have you tried? > > > > No, I kinda gave up on ALSA after reading its API (rather "functions > > that happen to be exported") documentation and kinda hoped it would go > > away ASAP. > > You give up reporting small hardware problems that bother you because the > application developer documentation for something is not in great shape? Yep, because I was frustrated with the whole thing. Having huge bad APIs with no documentation is telling your fellow developers to piss off and do something else. I did. It's not like a little oversight to be quickly forgotten. ALSA has been there for at least *five years* without documentation for most parts. > > hacking (i.e. more features faster). Latency is an issue? - Well you > > can't play sound without userspace creating it so you're not adding any > > new problems. > > Capture. > If you are not doing DMA from the sound card to kernel memory and then directly to disk blocks, you are using user space apps period. So what's different with capture? > Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/27/2007 06:25 PM, Andreas Hartmetz wrote: I don't like random applications blocking my sound card. So don't use random applications. You are concerned about your precious audio quality? Me too. Most people, however, are using god-awful plastic speakers for twenty euros and shitty onboard sound chips. Sad but true. Exactly, which is why mixing has been default for some time now for most cards. Are you only ranting about how it should've been earlier? ALSA appeared in 1999, KDE 2 with aRtsd (another catastrophic failure of technology) was released in october 2000. http://www.arts-project.org/gen/newsarchive/news_1998.html That sounds like a minor glitch that should be easily remedied if you file a proper bug report. Have you tried? No, I kinda gave up on ALSA after reading its API (rather "functions that happen to be exported") documentation and kinda hoped it would go away ASAP. You give up reporting small hardware problems that bother you because the application developer documentation for something is not in great shape? What an odd thing to do. And what a shame that this thread apparently was unable to outlive it's originator troll and turn useful... [ ... ] hacking (i.e. more features faster). Latency is an issue? - Well you can't play sound without userspace creating it so you're not adding any new problems. Capture. Rene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
> > The track record of ALSA for me goes like this:
> > - dmix finally started working automatically (at least on my Kubuntu
> > system) about one year ago, about five years after everybody could see
> > that this was badly needed.
>
> I don't remember when it happened, but I do remember that I suddenly
> had to manually disable dmix to stop it messing around with my sound.
> I don't need it, and I certainly don't like libraries doing random IPC
> behind my back.
>
I don't like random applications blocking my sound card.
Joe user wants to play sound, and he couldn't care less about "random IPC" or
what-fucking-ever.
Dmix using the low quality sampling rate converter by default was another bad
decision.
You are concerned about your precious audio quality? Me too. Most people,
however, are using god-awful plastic speakers for twenty euros and shitty
onboard sound chips. Sad but true.
> > - Different desktop environments have different sound daemons to
> > paper over the weaknesses of ALSA (no dmix by default / unfriendly
> > API), which creates new problems. Yes there are other reasons for
> > sound daemons, but I doubt anybody would have come up with the idea
> > if it wasn't for ALSA.
>
> Those sound daemons were around long before ALSA was even conceived.
>
ALSA appeared in 1999, KDE 2 with aRtsd (another catastrophic failure of
technology) was released in october 2000.
Linux 2.6.0 seems to have appeared in 2003, so you are right for realistic
values of "being around".
> That sounds like a minor glitch that should be easily remedied if you
> file a proper bug report. Have you tried?
>
No, I kinda gave up on ALSA after reading its API (rather "functions
that happen to be exported") documentation and kinda hoped it would go away
ASAP.
[long rant on ALSA's developer "friendliness"]
If you want to see an example try this one:
http://www.alsa-project.org/alsa-doc/alsa-lib/hcontrol.html
or this one
http://www.alsa-project.org/alsa-doc/alsa-lib/group___h_control.html#g881a1bbb1e95b7bcadc5c2a88124c3d1
and now program against it! Having fun already?
Observe how "HCTL"s seem to be used everywhere, and the documentation is
"typedef struct _snd_hctl_elem snd_hctl_elem_t : HCTL element handle". Wow.
the struct looks like this:
struct _snd_hctl_elem {
snd_ctl_elem_id_t id; /* must be always on top */
struct list_head list; /* links for list of all helems */
int compare_weight; /* compare weight (reversed) */
/* event callback */
snd_hctl_elem_callback_t callback;
void *callback_private;
/* links */
snd_hctl_t *hctl; /* associated handle */
};
Notice how compare_weight should probably be called comparison_weight or
priority, or relative_priority, or rel_priority or (...). The comment is
worse than no comment. The author couldn't be bothered to use a dictionary? I
think he wanted to tell us whether higher priorities have higher or lower
numbers, but I still don't know which.
callback_private should be callback_opaque. The construct has always been
called opaque pointer. If it was private it wasn't in this struct.
What about "must be always on top"??? Is it trying to tell us that you should
not randomize the struct layout?
Bonus points for using abbrvns ("helems") in cmts, thy r mch mr nformtv tht
wy.
There are two other structs of the same quality in the same header file
alsa-lib/control/control_local.h.
(control_local? As opposed to... remote? With a different interface or what?
It doesn't make any sense.)
This mess probably couldn't have survived a real review by the kernel
community.
For comparison, a comment taken from KDE's Phonon, copyright Matthias Kretz:
/**
* This signal is emitted whenever the volume has changed. As the
* volume can change without a call to setVolume (calls over dbus)
* this is important
* to keep a widget showing the current volume up to date.
*/
void volumeChanged(qreal newVolume);
Spot the difference?
Kernel or user space, again:
Put everything in kernel OR userspace but not both. Either is OK, but the
arguably more "modern" approach is userspace for error resilience and easy
hacking (i.e. more features faster). Latency is an issue? - Well you can't
play sound without userspace creating it so you're not adding any new
problems.
Kernel only would have the advantage of being able to present "everything as a
file" which is a good tradition. And no IPC.
ALSA took the disadvantages of both approaches and added the disadvantage of
having to get two chunks of code to get it working. It takes a twisted mind
to have two obvious right options and pick the third, obscure, and wrong
option. So sampling rate conversion is hard ("too dangerous for the kernel"),
boo hoo. It sure isn't more difficult to get right than a filesystem. Deal
with it.
History of ALSA:
I examined the lkml archive 1999 to 2002 a bit. There was much talk about
Re: Is it time for remove (crap) ALSA from kernel tree ?
Takashi Iwai wrote: > At Tue, 26 Jun 2007 12:25:16 -0400, > Wakko Warner wrote: > > I have a motherboard with an intel chipset and onboard audio. I have a > > problem with alsa. There's no pcm* files in /proc/asound/card0. > > Set CONFIG_SND_VERBOSE_PROCFS=y. GAH! Thanks, I didn't think I needed it but it is set on the one that works. -- Lab tests show that use of micro$oft causes cancer in lab animals Got Gas??? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
Takashi Iwai wrote: At Tue, 26 Jun 2007 12:25:16 -0400, Wakko Warner wrote: I have a motherboard with an intel chipset and onboard audio. I have a problem with alsa. There's no pcm* files in /proc/asound/card0. Set CONFIG_SND_VERBOSE_PROCFS=y. GAH! Thanks, I didn't think I needed it but it is set on the one that works. -- Lab tests show that use of micro$oft causes cancer in lab animals Got Gas??? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
The track record of ALSA for me goes like this:
- dmix finally started working automatically (at least on my Kubuntu
system) about one year ago, about five years after everybody could see
that this was badly needed.
I don't remember when it happened, but I do remember that I suddenly
had to manually disable dmix to stop it messing around with my sound.
I don't need it, and I certainly don't like libraries doing random IPC
behind my back.
I don't like random applications blocking my sound card.
Joe user wants to play sound, and he couldn't care less about random IPC or
what-fucking-ever.
Dmix using the low quality sampling rate converter by default was another bad
decision.
You are concerned about your precious audio quality? Me too. Most people,
however, are using god-awful plastic speakers for twenty euros and shitty
onboard sound chips. Sad but true.
- Different desktop environments have different sound daemons to
paper over the weaknesses of ALSA (no dmix by default / unfriendly
API), which creates new problems. Yes there are other reasons for
sound daemons, but I doubt anybody would have come up with the idea
if it wasn't for ALSA.
Those sound daemons were around long before ALSA was even conceived.
ALSA appeared in 1999, KDE 2 with aRtsd (another catastrophic failure of
technology) was released in october 2000.
Linux 2.6.0 seems to have appeared in 2003, so you are right for realistic
values of being around.
That sounds like a minor glitch that should be easily remedied if you
file a proper bug report. Have you tried?
No, I kinda gave up on ALSA after reading its API (rather functions
that happen to be exported) documentation and kinda hoped it would go away
ASAP.
[long rant on ALSA's developer friendliness]
If you want to see an example try this one:
http://www.alsa-project.org/alsa-doc/alsa-lib/hcontrol.html
or this one
http://www.alsa-project.org/alsa-doc/alsa-lib/group___h_control.html#g881a1bbb1e95b7bcadc5c2a88124c3d1
and now program against it! Having fun already?
Observe how HCTLs seem to be used everywhere, and the documentation is
typedef struct _snd_hctl_elem snd_hctl_elem_t : HCTL element handle. Wow.
the struct looks like this:
struct _snd_hctl_elem {
snd_ctl_elem_id_t id; /* must be always on top */
struct list_head list; /* links for list of all helems */
int compare_weight; /* compare weight (reversed) */
/* event callback */
snd_hctl_elem_callback_t callback;
void *callback_private;
/* links */
snd_hctl_t *hctl; /* associated handle */
};
Notice how compare_weight should probably be called comparison_weight or
priority, or relative_priority, or rel_priority or (...). The comment is
worse than no comment. The author couldn't be bothered to use a dictionary? I
think he wanted to tell us whether higher priorities have higher or lower
numbers, but I still don't know which.
callback_private should be callback_opaque. The construct has always been
called opaque pointer. If it was private it wasn't in this struct.
What about must be always on top??? Is it trying to tell us that you should
not randomize the struct layout?
Bonus points for using abbrvns (helems) in cmts, thy r mch mr nformtv tht
wy.
There are two other structs of the same quality in the same header file
alsa-lib/control/control_local.h.
(control_local? As opposed to... remote? With a different interface or what?
It doesn't make any sense.)
This mess probably couldn't have survived a real review by the kernel
community.
For comparison, a comment taken from KDE's Phonon, copyright Matthias Kretz:
/**
* This signal is emitted whenever the volume has changed. As the
* volume can change without a call to setVolume (calls over dbus)
* this is important
* to keep a widget showing the current volume up to date.
*/
void volumeChanged(qreal newVolume);
Spot the difference?
Kernel or user space, again:
Put everything in kernel OR userspace but not both. Either is OK, but the
arguably more modern approach is userspace for error resilience and easy
hacking (i.e. more features faster). Latency is an issue? - Well you can't
play sound without userspace creating it so you're not adding any new
problems.
Kernel only would have the advantage of being able to present everything as a
file which is a good tradition. And no IPC.
ALSA took the disadvantages of both approaches and added the disadvantage of
having to get two chunks of code to get it working. It takes a twisted mind
to have two obvious right options and pick the third, obscure, and wrong
option. So sampling rate conversion is hard (too dangerous for the kernel),
boo hoo. It sure isn't more difficult to get right than a filesystem. Deal
with it.
History of ALSA:
I examined the lkml archive 1999 to 2002 a bit. There was much talk about
using all the DSP, bass boost, and other sundry
Re: Is it time for remove (crap) ALSA from kernel tree ?
On 06/27/2007 06:25 PM, Andreas Hartmetz wrote: I don't like random applications blocking my sound card. So don't use random applications. You are concerned about your precious audio quality? Me too. Most people, however, are using god-awful plastic speakers for twenty euros and shitty onboard sound chips. Sad but true. Exactly, which is why mixing has been default for some time now for most cards. Are you only ranting about how it should've been earlier? ALSA appeared in 1999, KDE 2 with aRtsd (another catastrophic failure of technology) was released in october 2000. http://www.arts-project.org/gen/newsarchive/news_1998.html That sounds like a minor glitch that should be easily remedied if you file a proper bug report. Have you tried? No, I kinda gave up on ALSA after reading its API (rather functions that happen to be exported) documentation and kinda hoped it would go away ASAP. You give up reporting small hardware problems that bother you because the application developer documentation for something is not in great shape? What an odd thing to do. And what a shame that this thread apparently was unable to outlive it's originator troll and turn useful... [ ... ] hacking (i.e. more features faster). Latency is an issue? - Well you can't play sound without userspace creating it so you're not adding any new problems. Capture. Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
I don't like random applications blocking my sound card. So don't use random applications. I imitated the style of the mail I replied to. Besides, choosing apps based on sound system is retarded if you wanted to indicate that this should be done more often or something. You are concerned about your precious audio quality? Me too. Most people, however, are using god-awful plastic speakers for twenty euros and shitty onboard sound chips. Sad but true. Exactly, which is why mixing has been default for some time now for most cards. Are you only ranting about how it should've been earlier? Exactly! And the config file is hostile if you want to change it. ALSA appeared in 1999, KDE 2 with aRtsd (another catastrophic failure of technology) was released in october 2000. http://www.arts-project.org/gen/newsarchive/news_1998.html KDE 2 *was* released in 2000. Why would you care, I already admitted that sound daemons were there before ALSA. That sounds like a minor glitch that should be easily remedied if you file a proper bug report. Have you tried? No, I kinda gave up on ALSA after reading its API (rather functions that happen to be exported) documentation and kinda hoped it would go away ASAP. You give up reporting small hardware problems that bother you because the application developer documentation for something is not in great shape? Yep, because I was frustrated with the whole thing. Having huge bad APIs with no documentation is telling your fellow developers to piss off and do something else. I did. It's not like a little oversight to be quickly forgotten. ALSA has been there for at least *five years* without documentation for most parts. hacking (i.e. more features faster). Latency is an issue? - Well you can't play sound without userspace creating it so you're not adding any new problems. Capture. If you are not doing DMA from the sound card to kernel memory and then directly to disk blocks, you are using user space apps period. So what's different with capture? Rene. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
