* Re: [Alsa-user] AD1985 full-duplex(?) [not found] ` <20040818181350.2b38e875@mango.fruits.de> @ 2004-08-18 17:37 ` Jaroslav Kysela 2004-08-18 18:15 ` Florian Schmidt 0 siblings, 1 reply; 17+ messages in thread From: Jaroslav Kysela @ 2004-08-18 17:37 UTC (permalink / raw) To: Florian Schmidt Cc: Shaya Potter, Clemens Ladisch, Mauro Romano Trajber, ALSA development On Wed, 18 Aug 2004, Florian Schmidt wrote: > On Wed, 18 Aug 2004 08:27:10 -0700 > Shaya Potter <spotter@cs.columbia.edu> wrote: > > > A question I've asked, but haven't gotten an answer is why do we have > > to resort to dmix (i.e. something handled in userspace, and hence > > subject to the scheduler's whims as only one process can have control > > over the device) instead of being handled by the kernel driver itself > > (and hence not subject to the scheduler's whims as much) Really? If you have no new samples for playback, you cannot mix them. This situation is same for kernel and user space and depends on the scheduler. > I know how much the ALSA developers favor the modular approach having sw > mixing done in userspace. I think this is suboptimal for several > reasons: > > 1] the scheduling problems you mentioned No, the actual dmix implementation does not use mutexes, so rescheduling is not required. > 2] legacy OSS apps need to be run via aoss which still stinks for many > apps It's really problem, but it's problem that we need a compatibility with broken API (no library at the initial stage of design, so we cannot emulate OSS API directly without using hacks). Also at this time, nobody helped me to improve the liboss (aoss) code in some serious way. I ask why? Nobody uses it? Nobody wants this layer fully functional? I have another idea how we can solve this issue - a network sound driver, but this will add the scheduling problems including the throughput of the network layer, of course. > 3] the user has to edit configuration files, which is a showstopper for > newbies and people who have never had to follow a rigorous syntax. It's not a goal. In 90% of cases, you may simply use plug:dmix device which is already defined in the global configuration files. When integrated lisp is used, we'll solve the remaining 10% hardware constraints. > I would suggest writing another "dummy" soundcard module which would > sit "ontop" of the normal alsa driver and which does nothing but provide > sw mixing access [including the needed resampling and mixing]. It's not easy task and again, do we need to code it in the kernel space? Benefits? Target users? I think that we should provide the functionality (mixing) for all APIs, but the latency issues which mixing might invoke are not a serious problem. It's similar to graphics cards. You'll get better results with an accelerator (in case of sound with hardware having the mixing capability). Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Alsa-user] AD1985 full-duplex(?) 2004-08-18 17:37 ` [Alsa-user] AD1985 full-duplex(?) Jaroslav Kysela @ 2004-08-18 18:15 ` Florian Schmidt 2004-08-19 8:58 ` Jaroslav Kysela 0 siblings, 1 reply; 17+ messages in thread From: Florian Schmidt @ 2004-08-18 18:15 UTC (permalink / raw) To: Jaroslav Kysela Cc: Shaya Potter, Clemens Ladisch, Mauro Romano Trajber, ALSA development On Wed, 18 Aug 2004 19:37:16 +0200 (CEST) Jaroslav Kysela <perex@suse.cz> wrote: > > I know how much the ALSA developers favor the modular approach > > having sw mixing done in userspace. I think this is suboptimal for > > several reasons: > > > > 1] the scheduling problems you mentioned > > No, the actual dmix implementation does not use mutexes, so > rescheduling is not required. I see.. > > > 2] legacy OSS apps need to be run via aoss which still stinks for > > many apps > > It's really problem, but it's problem that we need a compatibility > with broken API (no library at the initial stage of design, so we > cannot emulate OSS API directly without using hacks). > > Also at this time, nobody helped me to improve the liboss (aoss) code > in some serious way. I ask why? Nobody uses it? Nobody wants this > layer fully functional? Hmm, you went on to make a wrapper for which the apps need to be changed at source code level. This is an option which is often not available [old games with makers who are broke whatever, closed source app where the vendor just refuses to fix it at all, etc.]. This is why i don't have any interest in improving it. I do have interest in improving aoss though wrt the traditional LD_PRELOAD hack.. But fixing the mmap issue was over my head [sorry], so i didn't go after it further. > > I have another idea how we can solve this issue - a network sound > driver, but this will add the scheduling problems including the > throughput of the network layer, of course. > > > 3] the user has to edit configuration files, which is a showstopper > > for newbies and people who have never had to follow a rigorous > > syntax. > > It's not a goal. In 90% of cases, you may simply use plug:dmix device > which is already defined in the global configuration files. yes, you're right. Btw: i also think there needs to be a predefined asym device which makes fullduplex access available for nultiple apps, too.. > > > I would suggest writing another "dummy" soundcard module which would > > sit "ontop" of the normal alsa driver and which does nothing but > > provide sw mixing access [including the needed resampling and > > mixing]. > > It's not easy task and again, do we need to code it in the kernel > space? Benefits? Target users? > > I think that we should provide the functionality (mixing) for all > APIs, but the latency issues which mixing might invoke are not a > serious problem. It's similar to graphics cards. You'll get better > results with an accelerator (in case of sound with hardware having the > mixing capability). > Yes. I just am not sure what is easier: a] fixing aoss to support all legacy oss apps [even those which cannot be changed at source code level] b] create a kernel module like the beforementioned which would just eliminate the issue for most users since they can just use the kernel level oss emu.. I really am not sure anymore. What do you think? Flo -- Palimm Palimm! http://affenbande.org/~tapas/ ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Alsa-user] AD1985 full-duplex(?) 2004-08-18 18:15 ` Florian Schmidt @ 2004-08-19 8:58 ` Jaroslav Kysela 2004-08-19 9:46 ` Takashi Iwai 2004-08-19 9:48 ` Florian Schmidt 0 siblings, 2 replies; 17+ messages in thread From: Jaroslav Kysela @ 2004-08-19 8:58 UTC (permalink / raw) To: Florian Schmidt Cc: Shaya Potter, Clemens Ladisch, Mauro Romano Trajber, ALSA development On Wed, 18 Aug 2004, Florian Schmidt wrote: > > Also at this time, nobody helped me to improve the liboss (aoss) code > > in some serious way. I ask why? Nobody uses it? Nobody wants this > > layer fully functional? > > Hmm, you went on to make a wrapper for which the apps need to be changed > at source code level. This is an option which is often not available > [old games with makers who are broke whatever, closed source app where > the vendor just refuses to fix it at all, etc.]. This is why i don't > have any interest in improving it. I do have interest in improving aoss > though wrt the traditional LD_PRELOAD hack.. > > But fixing the mmap issue was over my head [sorry], so i didn't go after > it further. Yep, but most bug reports are for quake or similar games. I don't play them and also I don't have useable supported hardware with the OpenGL, so I cannot test them. If you trace the code (I think that open source variants have similar OSS code) and create a simple test utility which can be run from the command line, I'll try to fix aoss. > > I have another idea how we can solve this issue - a network sound > > driver, but this will add the scheduling problems including the > > throughput of the network layer, of course. > > > > > 3] the user has to edit configuration files, which is a showstopper > > > for newbies and people who have never had to follow a rigorous > > > syntax. > > > > It's not a goal. In 90% of cases, you may simply use plug:dmix device > > which is already defined in the global configuration files. > > yes, you're right. Btw: i also think there needs to be a predefined asym > device which makes fullduplex access available for nultiple apps, too.. I agree. Do you have a nice idea for the PCM name? My ideas: mix xmulti (we have already multi plugin) shs (SHared Stream) shd (SHared Device) ??? > > > I would suggest writing another "dummy" soundcard module which would > > > sit "ontop" of the normal alsa driver and which does nothing but > > > provide sw mixing access [including the needed resampling and > > > mixing]. > > > > It's not easy task and again, do we need to code it in the kernel > > space? Benefits? Target users? > > > > I think that we should provide the functionality (mixing) for all > > APIs, but the latency issues which mixing might invoke are not a > > serious problem. It's similar to graphics cards. You'll get better > > results with an accelerator (in case of sound with hardware having the > > mixing capability). > > > > Yes. I just am not sure what is easier: > > a] fixing aoss to support all legacy oss apps [even those which cannot > be changed at source code level] > > b] create a kernel module like the beforementioned which would just > eliminate the issue for most users since they can just use the kernel > level oss emu.. My plan is fix aoss and create a network sound device inside kernel, so we can reroute OSS streams from kernel to userspace, too. Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: [Alsa-user] AD1985 full-duplex(?) 2004-08-19 8:58 ` Jaroslav Kysela @ 2004-08-19 9:46 ` Takashi Iwai 2004-08-19 10:28 ` Jaroslav Kysela 2004-08-19 9:48 ` Florian Schmidt 1 sibling, 1 reply; 17+ messages in thread From: Takashi Iwai @ 2004-08-19 9:46 UTC (permalink / raw) To: Jaroslav Kysela Cc: Florian Schmidt, Shaya Potter, Clemens Ladisch, Mauro Romano Trajber, ALSA development At Thu, 19 Aug 2004 10:58:04 +0200 (CEST), Jaroslav wrote: > > On Wed, 18 Aug 2004, Florian Schmidt wrote: > > > > Also at this time, nobody helped me to improve the liboss (aoss) code > > > in some serious way. I ask why? Nobody uses it? Nobody wants this > > > layer fully functional? > > > > Hmm, you went on to make a wrapper for which the apps need to be changed > > at source code level. This is an option which is often not available > > [old games with makers who are broke whatever, closed source app where > > the vendor just refuses to fix it at all, etc.]. This is why i don't > > have any interest in improving it. I do have interest in improving aoss > > though wrt the traditional LD_PRELOAD hack.. > > > > But fixing the mmap issue was over my head [sorry], so i didn't go after > > it further. > > Yep, but most bug reports are for quake or similar games. I don't play > them and also I don't have useable supported hardware with the OpenGL, so > I cannot test them. If you trace the code (I think that open source > variants have similar OSS code) and create a simple test utility which can > be run from the command line, I'll try to fix aoss. Sigh, quake is always a bad boy... > > > I have another idea how we can solve this issue - a network sound > > > driver, but this will add the scheduling problems including the > > > throughput of the network layer, of course. > > > > > > > 3] the user has to edit configuration files, which is a showstopper > > > > for newbies and people who have never had to follow a rigorous > > > > syntax. > > > > > > It's not a goal. In 90% of cases, you may simply use plug:dmix device > > > which is already defined in the global configuration files. > > > > yes, you're right. Btw: i also think there needs to be a predefined asym > > device which makes fullduplex access available for nultiple apps, too.. > > I agree. Do you have a nice idea for the PCM name? My ideas: > > mix I like this one. > xmulti (we have already multi plugin) > shs (SHared Stream) > shd (SHared Device) > > ??? > > > > > I would suggest writing another "dummy" soundcard module which would > > > > sit "ontop" of the normal alsa driver and which does nothing but > > > > provide sw mixing access [including the needed resampling and > > > > mixing]. > > > > > > It's not easy task and again, do we need to code it in the kernel > > > space? Benefits? Target users? > > > > > > I think that we should provide the functionality (mixing) for all > > > APIs, but the latency issues which mixing might invoke are not a > > > serious problem. It's similar to graphics cards. You'll get better > > > results with an accelerator (in case of sound with hardware having the > > > mixing capability). > > > > > > > Yes. I just am not sure what is easier: > > > > a] fixing aoss to support all legacy oss apps [even those which cannot > > be changed at source code level] > > > > b] create a kernel module like the beforementioned which would just > > eliminate the issue for most users since they can just use the kernel > > level oss emu.. > > My plan is fix aoss and create a network sound device inside kernel, so we > can reroute OSS streams from kernel to userspace, too. Can "network sound device" work with the mmap, too? Takashi ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: [Alsa-user] AD1985 full-duplex(?) 2004-08-19 9:46 ` Takashi Iwai @ 2004-08-19 10:28 ` Jaroslav Kysela 2004-08-23 11:36 ` Adam Tlałka 0 siblings, 1 reply; 17+ messages in thread From: Jaroslav Kysela @ 2004-08-19 10:28 UTC (permalink / raw) To: Takashi Iwai Cc: Florian Schmidt, Shaya Potter, Clemens Ladisch, Mauro Romano Trajber, ALSA development On Thu, 19 Aug 2004, Takashi Iwai wrote: > Can "network sound device" work with the mmap, too? I think yes, it can, but the real output will be more delayd. So, it won't be much useable for the strict real-time applications. Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: [Alsa-user] AD1985 full-duplex(?) 2004-08-19 10:28 ` Jaroslav Kysela @ 2004-08-23 11:36 ` Adam Tlałka 2004-08-23 11:54 ` Jaroslav Kysela 2004-08-23 15:30 ` Takashi Iwai 0 siblings, 2 replies; 17+ messages in thread From: Adam Tlałka @ 2004-08-23 11:36 UTC (permalink / raw) To: alsa-devel > On Thu, 19 Aug 2004, Takashi Iwai wrote: >>Can "network sound device" work with the mmap, too? > I think yes, it can, but the real output will be more delayd. So, it won't > be much useable for the strict real-time applications. But old quake and new quake3 and some OSS apps use mmap mode for better timing and accurate mixing so will it be usable if done that way? As talking about network transparency it is a good idea but what about more system independent solution - look at MASS for example (link from www.x.org). I personally think that local sound should be done as effective as it can be so doing it through network layer is not a nice idea - maybe IPC and non swappable shared memory should be used to transfer data between kernel and user space to used ALSA mix/asym advantages. I have a modified aoss lib which plays quake1 - quake3 and other apps simulataniously but this is not a perfect solution. Sometimes sound is distorted and some apps are not working (these using SDL and poll method - some time issues probably). This method not supports multichannel sources (4, 5.1, 7.1) so OSS compatibility is not full. I need volume regulation per source too which is missing. OSS emulation in kernel is not fully compatible with OSS too so some native OSS apps will not work. Regards -- Adam Tla/lka mailto:atlka@pg.gda.pl ^v^ ^v^ ^v^ System & Network Administration Group ~~~~~~ Computer Center, Gdansk University of Technology, Poland PGP public key: finger atlka@sunrise.pg.gda.pl ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: [Alsa-user] AD1985 full-duplex(?) 2004-08-23 11:36 ` Adam Tlałka @ 2004-08-23 11:54 ` Jaroslav Kysela 2004-08-23 12:34 ` Adam Tlałka 2004-08-23 15:30 ` Takashi Iwai 1 sibling, 1 reply; 17+ messages in thread From: Jaroslav Kysela @ 2004-08-23 11:54 UTC (permalink / raw) To: Adam Tlałka; +Cc: alsa-devel On Mon, 23 Aug 2004, Adam Tlałka wrote: > > On Thu, 19 Aug 2004, Takashi Iwai wrote: > >>Can "network sound device" work with the mmap, too? > > I think yes, it can, but the real output will be more delayd. So, it won't > > be much useable for the strict real-time applications. > But old quake and new quake3 and some OSS apps use mmap mode for better > timing and accurate mixing so will it be usable if done that way? I already stated: If you want to use real-time applications, buy real-time hardware. > As talking about network transparency it is a good idea but what about > more system independent solution - look at MASS for example > (link from www.x.org). > I personally think that local sound should be done as effective as it > can be so doing it through network layer is not a nice idea - maybe IPC > and non swappable shared memory should be used to transfer data > between kernel and user space to used ALSA mix/asym advantages. We can do a similar extension like xshm in X-window in the network sound driver. You need always a "control" channel between kernel and user space. Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: [Alsa-user] AD1985 full-duplex(?) 2004-08-23 11:54 ` Jaroslav Kysela @ 2004-08-23 12:34 ` Adam Tlałka 2004-08-23 14:39 ` Jaroslav Kysela 0 siblings, 1 reply; 17+ messages in thread From: Adam Tlałka @ 2004-08-23 12:34 UTC (permalink / raw) To: alsa-devel > On Mon, 23 Aug 2004, Adam Tlałka wrote: > > >>>On Thu, 19 Aug 2004, Takashi Iwai wrote: >>> >>>>Can "network sound device" work with the mmap, too? >>> >>>I think yes, it can, but the real output will be more delayd. So, it won't >>>be much useable for the strict real-time applications. >> >>But old quake and new quake3 and some OSS apps use mmap mode for better >>timing and accurate mixing so will it be usable if done that way? > > > I already stated: If you want to use real-time applications, buy real-time > hardware. They are rather normal user applications then specialized RT apps - I don't want to buy specialized hardware just to play some games or mix system sounds with browser and communicator apps sounds. Also switching two, 4 or 5.1 mode and headphone mode should be done just by one click without application restarting. So down/up mixing should be in a driver. I think it can't be done with todays ALSA in lib functionality approach and never will be. Regards -- Adam Tla/lka mailto:atlka@pg.gda.pl ^v^ ^v^ ^v^ System & Network Administration Group ~~~~~~ Computer Center, Gdansk University of Technology, Poland PGP public key: finger atlka@sunrise.pg.gda.pl ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: [Alsa-user] AD1985 full-duplex(?) 2004-08-23 12:34 ` Adam Tlałka @ 2004-08-23 14:39 ` Jaroslav Kysela 2004-08-24 6:01 ` Adam Tla/lka 0 siblings, 1 reply; 17+ messages in thread From: Jaroslav Kysela @ 2004-08-23 14:39 UTC (permalink / raw) To: Adam Tlałka; +Cc: alsa-devel On Mon, 23 Aug 2004, Adam Tlałka wrote: > > I already stated: If you want to use real-time applications, buy real-time > > hardware. > They are rather normal user applications then specialized RT apps - I > don't want to buy specialized hardware just to play some games > or mix system sounds with browser and communicator apps sounds. Quake is special case. For standard applications, the mixing should be provided, but there're not latency issues. I still think that the aoss library can be fixed so that quake will work. I think that OSS/Commercial also adds some delay on their "virtual" devices mixed together. > Also switching two, 4 or 5.1 mode and headphone mode should be done > just by one click without application restarting. So down/up mixing > should be in a driver. I think it can't be done with todays ALSA in lib > functionality approach and never will be. Why not? Most today's hardware can reroute samples or analog paths in hardware. So it's only about right mixer setup. Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: [Alsa-user] AD1985 full-duplex(?) 2004-08-23 14:39 ` Jaroslav Kysela @ 2004-08-24 6:01 ` Adam Tla/lka 0 siblings, 0 replies; 17+ messages in thread From: Adam Tla/lka @ 2004-08-24 6:01 UTC (permalink / raw) To: alsa-devel On Mon, Aug 23, 2004 at 04:39:20PM +0200, Jaroslav Kysela wrote: > Quake is special case. For standard applications, the mixing should be > provided, but there're not latency issues. OK - but some old apps use DMA ring buffer and they should work properly too. > > I still think that the aoss library can be fixed so that quake will work. > I think that OSS/Commercial also adds some delay on their "virtual" > devices mixed together. Sure but aoss sometimes produces clicks and bad sound effects. Switching to other app and then returning to previous one helps. I have patched aoss which plays quake1 - quake3 in MMAP mode but it is not perfect. Also some apps which use poll don't work at all (old game Shogo) - SDL report timing problems and disables sound. aoss approach doesn't work at all with apss which are completly static or disabling LD_PRELOAD. > Why not? Most today's hardware can reroute samples or analog paths in > hardware. So it's only about right mixer setup. As I said before I dont want to buy expensive mambo-jubo card just to mix stereo, mono and 5.1 sources together at the same time with the proper up/down sampling, channel volume control and sound phase correction. I think that driver should use all card abilities and emulate other in software. If I put headphones on my head I just want to use one switch in mixer app to turn on headphones mode. The same in opposite direction. Regards -- Adam Tla/lka mailto:atlka@pg.gda.pl ^v^ ^v^ ^v^ System & Network Administration Group ~~~~~~ Computer Center, Gdansk University of Technology, Poland PGP public key: finger atlka@sunrise.pg.gda.pl ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: [Alsa-user] AD1985 full-duplex(?) 2004-08-23 11:36 ` Adam Tlałka 2004-08-23 11:54 ` Jaroslav Kysela @ 2004-08-23 15:30 ` Takashi Iwai 2004-08-28 19:10 ` Adam Tlałka 1 sibling, 1 reply; 17+ messages in thread From: Takashi Iwai @ 2004-08-23 15:30 UTC (permalink / raw) To: Adam Tlałka; +Cc: alsa-devel At Mon, 23 Aug 2004 13:36:02 +0200, Adam Tlałka wrote: > > > On Thu, 19 Aug 2004, Takashi Iwai wrote: > >>Can "network sound device" work with the mmap, too? > > I think yes, it can, but the real output will be more delayd. So, it won't > > be much useable for the strict real-time applications. > But old quake and new quake3 and some OSS apps use mmap mode for better > timing and accurate mixing I doubt it. Mmap doesn't provide better nor accurate "timing" although it provides more efficient data transfer method. The accuracy depends on the fineness of DMA interrupts and the scheduler latency. I don't see so big requirement of mmap in this regard. If you need a free-running ring buffer, you can do it simply by setting the proper stop_threshold for disabling XRUN detection. The perfomance win by mmap is far little in comparison with computations of mixing and effects. Hence, what I see here is only the demand of "compatibility". From the performance perspective, there is no reason to force mmap. Note that I don't mention here about apps with high bandwidth like HDR but apps with normal 16bit/48k sounds with at most 6 voices in the background. Also, I don't mean that network system can provide as good response as the normal system. What I mean is that the discussion of latency should be indepdent from necessity of mmap implementaion. Takashi ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: [Alsa-user] AD1985 full-duplex(?) 2004-08-23 15:30 ` Takashi Iwai @ 2004-08-28 19:10 ` Adam Tlałka 2004-08-29 9:54 ` Jaroslav Kysela 0 siblings, 1 reply; 17+ messages in thread From: Adam Tlałka @ 2004-08-28 19:10 UTC (permalink / raw) To: alsa-devel [2004-08-23 17:30] Takashi Iwai: >>>>Can "network sound device" work with the mmap, too? >>>I think yes, it can, but the real output will be more delayd. So, it won't >>>be much useable for the strict real-time applications. If "network" mode for OSS ALSA emulation in kernel will give us worse results than real OSS then I prefer to use real OSS drivers :-( - on the same machine. Playing quake or other MMAP mode games with networked sound is not a real target anyway. > effects. Hence, what I see here is only the demand of > "compatibility". From the performance perspective, there is no reason > to force mmap. Of course I agree with that. It can't be perfect because of emulation but should be here for some old apps - and should work properly with them. I imagine sound system as some layered structure: program | v dev -> redirecting, routing and up/down mixing kernel layer | | v v kernel device driver net | v hardware in ALSA it looks like program | v alsalib (plugins for routing, resampling and mixing) -> kernel driver -> hardware -> net (in the future) I prefer normal Unix way (device and standard functions plus ioctl) so if we can do a kernel module which does routing, redirecting and resampling on top of free OSS module we could obtain full functionality without any change in OSS programs. But that's OSS not ALSA. In ALSA we need some kernel module which routes virtual OSS channels from kernel space to user space in ALSA lib emulation. I don't know how effective it will be but if we decided to mix in lib then this is the only way. By the way in ALSA README we read about full OSS ALSA compatibility. But this is not true!!! No mixer calls on dsp stream, no multichannel streams (4...7.1) are possible with OSS emulation, DMA mode broken. I just can't abandon using OSS because of that :-(. There are many sound daemons apps. I just don't want to link an app with all their libraries. It should just open and use sound device - kernel module should communicate with deamon to hide its presence before an app - that is the proper way IMHO. Standard Unix approach plus some message passing method if we can't do all in kernel. So what is the future of Linux sound?? Regards -- Adam Tla/lka mailto:atlka@pg.gda.pl ^v^ ^v^ ^v^ System & Network Administration Group ~~~~~~ Computer Center, Gdansk University of Technology, Poland PGP public key: finger atlka@sunrise.pg.gda.pl ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: [Alsa-user] AD1985 full-duplex(?) 2004-08-28 19:10 ` Adam Tlałka @ 2004-08-29 9:54 ` Jaroslav Kysela 2004-08-29 18:35 ` Adam Tlałka 0 siblings, 1 reply; 17+ messages in thread From: Jaroslav Kysela @ 2004-08-29 9:54 UTC (permalink / raw) To: Adam Tlałka; +Cc: alsa-devel On Sat, 28 Aug 2004, Adam Tlałka wrote: > I imagine sound system as some layered structure: > > program > | > v > dev -> redirecting, routing and up/down mixing kernel layer > | | > v v > kernel device driver net > | > v > hardware It's kernel centristic view. I don't see much reasons to have everything in kernel. > in ALSA it looks like > > program > | > v > alsalib (plugins for routing, resampling and mixing) -> kernel driver -> > hardware > -> > net (in the future) What about this direct way: program -> alsa-lib -> net ? I proposed network driver mainly to solve OSS redirecting problems. We can implement this driver completely in user space. > I prefer normal Unix way (device and standard functions plus ioctl) so > if we can do a kernel module which does routing, redirecting and > resampling on top of free OSS module we could obtain full functionality > without any change in OSS programs. But that's OSS not ALSA. > > In ALSA we need some kernel module which routes virtual OSS channels > from kernel space to user space in ALSA lib emulation. I don't know how > effective it will be but if we decided to mix in lib then this is the > only way. > > By the way in ALSA README we read about full OSS ALSA compatibility. > But this is not true!!! > No mixer calls on dsp stream, Huh, that's new for me. It does not work? It's implemented. > no multichannel streams (4...7.1) are possible with OSS emulation, Additional information which is moved to alsa-lib is required. Anyway, actually almost all new applications requiring this feature support ALSA. > DMA mode broken. I just can't abandon using OSS because of that :-(. Could you specify which is broken with the kernel ALSA's OSS mmap emulation? > There are many sound daemons apps. I just don't want to link an app with > all their libraries. It should just open and use sound device - kernel > module should communicate with deamon to hide its presence before an app > - that is the proper way IMHO. Standard Unix approach plus some message > passing method if we can't do all in kernel. > > So what is the future of Linux sound?? Note that the direct device access is the major problem with the OSS API. If a library which hide the direct syscalls exists, we never had such problems to redirect OSS calls to our code. The library can be very small. I already wrote an OSS redirector (alsa-oss/oss-redir) but it might be that this project will be totaly ignored, because I am not able to do much advertisements for all OSS developers to use these calls rather than direct device accesses. I feel that it's mainly about fixing bugs. Unfortunately, most of users (including you) point me to quake binaries. I cannot run them on my machines. The installation always fails at some point (OpenGL, missing .wad files for full quake version etc.). If you show me a little command style code which triggers different bugs in the OSS emulation layer, I promise, I will fix them. Anyway, this call is to all people on this list. Could you create a Wiki page which exact (version, source URL) OSS applications have trouble with: 1) ALSA's kernel OSS emulation 2) ALSA's aoss (libaoss) It will also help me a lot to finish the OSS emulation and stop these complains. Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: [Alsa-user] AD1985 full-duplex(?) 2004-08-29 9:54 ` Jaroslav Kysela @ 2004-08-29 18:35 ` Adam Tlałka 2004-08-31 8:09 ` Jaroslav Kysela 0 siblings, 1 reply; 17+ messages in thread From: Adam Tlałka @ 2004-08-29 18:35 UTC (permalink / raw) To: alsa-devel [2004-08-29 11:54] Jaroslav Kysela: > On Sat, 28 Aug 2004, Adam Tlałka wrote: > > >>I imagine sound system as some layered structure: >> >>program >>| >>v >>dev -> redirecting, routing and up/down mixing kernel layer >> | | >> v v >> kernel device driver net >> | >> v >> hardware > > > It's kernel centristic view. I don't see much reasons to have everything > in kernel. Because of latency issues and need for direct access to hardware it's sometimes better to have this functions in kernel - if card can mix in hardware N streams use that feature for N streams but if you need N+1 then you must do it in software. If again streams count lowers to N you should return to hardware mixing. I can't see this is possible with current ALSA dmix plugin. > What about this direct way: program -> alsa-lib -> net ? > I proposed network driver mainly to solve OSS redirecting problems. > We can implement this driver completely in user space. OK it was my error - bad spaceing - you are right. >>No mixer calls on dsp stream, > Huh, that's new for me. It does not work? It's implemented. Maybe with kernel emulation, but not in aoss. >>no multichannel streams (4...7.1) are possible with OSS emulation, > Additional information which is moved to alsa-lib is required. Anyway, > actually almost all new applications requiring this feature support ALSA. OK, but OSS compability is not full. >>DMA mode broken. I just can't abandon using OSS because of that :-(. > Could you specify which is broken with the kernel ALSA's OSS mmap > emulation? I am not using kernel module. I am using patched aoss lib and dmix plugin. I think that we should carefully read OSS pdf doc and look at the OSS emulation code to find which is not compatible with documented original OSS behaviour. As I can tell there is one thing according to DMA mode - buffer size and number of periods. In original OSS for example GETOSPACE call reports these values and after that call or any of GETxPTR, GETxDELAY, read or write operation these values are fixed. So if an app read buffer size and num of periods first and then sets stream parameters (format, stereo, rate) buffer size and num of periods are not changed - in original OSS. If we changing parameters using ALSA lib buffer size and num of periods could change so if we now have different OSS values some apps just broke. OK - this app behaviour is not quite correct - it should set stream parameters first and ask about buffer size after that. But this is an original OSS documented behaviour so it should be supported. > Note that the direct device access is the major problem with the OSS API. I don't think so. You don't need to link an app with any additional libraries and these device open, read, write, select, poll and ioctl are just normal Unix filesystem calls. We only should have kernel module which could redirect data stream and control to user space (maybe RT) daemon which does the rest. program -> OSS dev -> redirector module -> special RT daemon -> alsa lib -> card > If a library which hide the direct syscalls exists, we never had such > problems to redirect OSS calls to our code. The library can be very > small. But we have some closed source proprietary apps which should work too. > I feel that it's mainly about fixing bugs. Unfortunately, most of users > (including you) point me to quake binaries. I cannot run them on my > machines. Hmm, I am frequently testing aoss with quake.x11 (quake1) binary which is plain X11 app - no OpenGL. I don't now how is accesible quake2 in your country but I just bought cheap CD with full version in some multimedia store. quake1 and quake2 program sources are accesible on the net. > Anyway, this call is to all people on this list. Could you create a Wiki > page which exact (version, source URL) OSS applications have trouble with: > > 1) ALSA's kernel OSS emulation > 2) ALSA's aoss (libaoss) OK if I find some time and test this more I write some info. Regards -- Adam Tla/lka mailto:atlka@pg.gda.pl ^v^ ^v^ ^v^ System & Network Administration Group ~~~~~~ Computer Center, Gdansk University of Technology, Poland PGP public key: finger atlka@sunrise.pg.gda.pl ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: [Alsa-user] AD1985 full-duplex(?) 2004-08-29 18:35 ` Adam Tlałka @ 2004-08-31 8:09 ` Jaroslav Kysela 0 siblings, 0 replies; 17+ messages in thread From: Jaroslav Kysela @ 2004-08-31 8:09 UTC (permalink / raw) To: Adam Tlałka; +Cc: ALSA development On Sun, 29 Aug 2004, Adam Tlałka wrote: > Because of latency issues and need for direct access to hardware it's > sometimes better to have this functions in kernel - if card can mix in > hardware N streams use that feature for N streams but if you need N+1 > then you must do it in software. If again streams count lowers to N you > should return to hardware mixing. I can't see this is possible with > current ALSA dmix plugin. It can be implemented also in the user space. If open() of raw hw:X,Y device fails, then dmix can be used. We can eventually use a threshold to leave some voices for wavetable etc. > >>No mixer calls on dsp stream, > > Huh, that's new for me. It does not work? It's implemented. > Maybe with kernel emulation, but not in aoss. OK, it's right. Please, make a bugreport. > >>no multichannel streams (4...7.1) are possible with OSS emulation, > > Additional information which is moved to alsa-lib is required. Anyway, > > actually almost all new applications requiring this feature support ALSA. > OK, but OSS compability is not full. Yes, I fixed README which was very old. > >>DMA mode broken. I just can't abandon using OSS because of that :-(. > > Could you specify which is broken with the kernel ALSA's OSS mmap > > emulation? > > I am not using kernel module. I am using patched aoss lib and dmix > plugin. I think that we should carefully read OSS pdf doc and look at > the OSS emulation code to find which is not compatible with documented > original OSS behaviour. As I can tell there is one thing according to > DMA mode - buffer size and number of periods. In original OSS for > example GETOSPACE call reports these values and after that call or any > of GETxPTR, GETxDELAY, read or write operation these values are fixed. > So if an app read buffer size and num of periods first and then sets > stream parameters (format, stereo, rate) buffer size and num of periods > are not changed - in original OSS. If we changing parameters using ALSA > lib buffer size and num of periods could change so if we now have > different OSS values some apps just broke. OK - this app behaviour is > not quite correct - it should set stream parameters first and ask about > buffer size after that. But this is an original OSS documented behaviour > so it should be supported. Yes, some test utilities will be fine. > > Note that the direct device access is the major problem with the OSS API. > I don't think so. You don't need to link an app with any additional > libraries and these device open, read, write, select, poll and ioctl are > just normal Unix filesystem calls. We only should have kernel module > which could redirect data stream and control to user space (maybe RT) > daemon which does the rest. I meant that the library had to be used from the initial stage of the OSS API design like we have alsa-lib. Yes, now is too late at least for static linked applications. > program -> OSS dev -> redirector module -> special RT daemon -> alsa lib > -> card I would replace redirector module with network or direct loopback driver module. In this case ALSA applications can benefit as well. > > If a library which hide the direct syscalls exists, we never had such > > problems to redirect OSS calls to our code. The library can be very > > small. > But we have some closed source proprietary apps which should work too. Yes, bad initial API design. > > I feel that it's mainly about fixing bugs. Unfortunately, most of users > > (including you) point me to quake binaries. I cannot run them on my > > machines. > Hmm, I am frequently testing aoss with quake.x11 (quake1) binary which > is plain X11 > app - no OpenGL. I don't now how is accesible quake2 in your country > but I just bought cheap CD with full version in some multimedia store. > quake1 and quake2 program sources are accesible on the net. If we have the sources, could you extract the audio code and prepare a short test command line code? It would be very useful for debugging. Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: [Alsa-user] AD1985 full-duplex(?) 2004-08-19 8:58 ` Jaroslav Kysela 2004-08-19 9:46 ` Takashi Iwai @ 2004-08-19 9:48 ` Florian Schmidt 2004-08-20 10:58 ` Jaroslav Kysela 1 sibling, 1 reply; 17+ messages in thread From: Florian Schmidt @ 2004-08-19 9:48 UTC (permalink / raw) To: Jaroslav Kysela Cc: Shaya Potter, Clemens Ladisch, Mauro Romano Trajber, ALSA development On Thu, 19 Aug 2004 10:58:04 +0200 (CEST) Jaroslav Kysela <perex@suse.cz> wrote: > > But fixing the mmap issue was over my head [sorry], so i didn't go > > after it further. > > Yep, but most bug reports are for quake or similar games. I don't play > them and also I don't have useable supported hardware with the OpenGL, > so I cannot test them. If you trace the code (I think that open source > variants have similar OSS code) and create a simple test utility which > can be run from the command line, I'll try to fix aoss. I think there are opensourced versions of _some_ of these old games. I'll take a look. If i don't find anything i'll try to write an oss test app that uses mmap and fails similarly. > > yes, you're right. Btw: i also think there needs to be a predefined > > asym device which makes fullduplex access available for nultiple > > apps, too.. > > I agree. Do you have a nice idea for the PCM name? My ideas: > > mix > xmulti (we have already multi plugin) > shs (SHared Stream) > shd (SHared Device) simply "shared" maybe? "mix" doesn't quite fit it, since it only describes the playback direction and it's maybe too similar to "dmix". Or stick to the way it was done with the dmix plugin. Call the predefined device using asym simply "asym". > > a] fixing aoss to support all legacy oss apps [even those which > > cannot be changed at source code level] > > > > b] create a kernel module like the beforementioned which would just > > eliminate the issue for most users since they can just use the > > kernel level oss emu.. > > My plan is fix aoss and create a network sound device inside kernel, > so we can reroute OSS streams from kernel to userspace, too. May i ask, why your planning to make this networked? I read some articles about user space file systems [which get utilized by kernel modules] a while back. I think that networking introduces another layer of complexity. You think this is nessecary? hmm, some links i found in my bookmarks: http://okmij.org/ftp/syscall-interpose.html http://www.circlemud.org/~jelson/software/fusd/ regards, flo ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: [Alsa-user] AD1985 full-duplex(?) 2004-08-19 9:48 ` Florian Schmidt @ 2004-08-20 10:58 ` Jaroslav Kysela 0 siblings, 0 replies; 17+ messages in thread From: Jaroslav Kysela @ 2004-08-20 10:58 UTC (permalink / raw) To: Florian Schmidt Cc: Shaya Potter, Clemens Ladisch, Mauro Romano Trajber, ALSA development On Thu, 19 Aug 2004, Florian Schmidt wrote: > May i ask, why your planning to make this networked? I read some > articles about user space file systems [which get utilized > by kernel modules] a while back. I think that networking introduces > another layer of complexity. You think this is nessecary? It's more interesting development and as bonus we get remote audio devices. Jaroslav ----- Jaroslav Kysela <perex@suse.cz> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2004-08-31 8:20 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <Pine.HPX.4.33n.0408181538550.24798-100000@studcom.urz.uni-halle.de>
[not found] ` <1092842830.13603.3.camel@localhost.localdomain>
[not found] ` <20040818181350.2b38e875@mango.fruits.de>
2004-08-18 17:37 ` [Alsa-user] AD1985 full-duplex(?) Jaroslav Kysela
2004-08-18 18:15 ` Florian Schmidt
2004-08-19 8:58 ` Jaroslav Kysela
2004-08-19 9:46 ` Takashi Iwai
2004-08-19 10:28 ` Jaroslav Kysela
2004-08-23 11:36 ` Adam Tlałka
2004-08-23 11:54 ` Jaroslav Kysela
2004-08-23 12:34 ` Adam Tlałka
2004-08-23 14:39 ` Jaroslav Kysela
2004-08-24 6:01 ` Adam Tla/lka
2004-08-23 15:30 ` Takashi Iwai
2004-08-28 19:10 ` Adam Tlałka
2004-08-29 9:54 ` Jaroslav Kysela
2004-08-29 18:35 ` Adam Tlałka
2004-08-31 8:09 ` Jaroslav Kysela
2004-08-19 9:48 ` Florian Schmidt
2004-08-20 10:58 ` Jaroslav Kysela
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.