[Alsa-devel] buffer producer/consumer sync
Title: buffer producer/consumer sync
hi ,
While debugging my alsa driver , some observations...
The flow goes like this
- cat test.raw > /dev/pcm
- Middle layer fills up the buffer (size = period_size). Why does middle layer only fills up period_size ??
- ...(open / init etc)
- Trigger with PLAY command is called
a) audio_dma_process routine is called
This routine starts a dma transfer for a size of period_size
b) We get a end of transfer interrupt and our callback is called. In the callback function we call snd_pcm_period_elapsed to notify that one period is finished. This function causes Trigger to be called again with STOP and then START again. And the reason which I found after much debugging is this :
--
if (avail >= runtime->stop_threshold) {
snd_pcm_stop(substream,
runtime->status->state == SNDRV_PCM_STATE_DRAINING ?
SNDRV_PCM_STATE_SETUP : SNDRV_PCM_STATE_XRUN);
this code is a part of snd_pcm_update_hw_ptr_post function in sound/core/pcm_lib.c
--
avail value is coming equal to runtime->stop_threshold and that is why we are getting a stop. A trace of these values is :
initially
hw_ptr = 0 appl_ptr = period_size avail = runtime->buffersize stop_threshold = runtime->buffersize (this is set by default)
after one DMA transfer
hw_ptr = period_size appl_ptr = period_size(still the same value ... middle layer should have filled in more data and updated this )
avail = hw_ptr + runtime->buffersize - appl_ptr
so again avail = runtime->buffersize , since hw_ptr is equal to appl_ptr.
What we analyzed here is that After the DMA transfer starts and before the finish of the DMA transfer the alsa middle layer should fill up data from application layer (cat command in this context). So probably DMA transfer is happening at a much faster rate than the middle layer can fill up more application buffers.
Can someone comment on this and guide a little bit to solve this problem.
warm regards
-kshitij
Re: [Alsa-devel] buffer producer/consumer sync
On Tue, 9 Mar 2004, Gupta, Kshitij wrote: > > Can someone comment on this and guide a little bit to solve this problem. Yes, on ARM platform you might have problem with MMU / cache coherency, because appl_ptr and hw_ptr are mmaped to user space. I observed this behaviour on SA11xx platform, too. Russell King already notified us about this problem. See the mail archive for the proper fix of the midlevel code. Jaroslav - Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] buffer producer/consumer sync
On Tue, Mar 09, 2004 at 10:53:57AM +0100, Jaroslav Kysela wrote: > On Tue, 9 Mar 2004, Gupta, Kshitij wrote: > > > Can someone comment on this and guide a little bit to solve this problem. > > Yes, on ARM platform you might have problem with MMU / cache coherency, > because appl_ptr and hw_ptr are mmaped to user space. I observed this > behaviour on SA11xx platform, too. > > Russell King already notified us about this problem. See the mail archive > for the proper fix of the midlevel code. There currently doesn't exist a public fix for this yet, so people using ARM platforms will have to live without ALSA for the time being. (Actually, you can still use ALSA but you must use OSS PCM emulation.) As you say, appl_ptr and hw_ptr have cache coherency problems. However, a portable and acceptable solution does not exist today to solve this problem which would be acceptable to ALSA. The current preferred solution is to call flush_dcache_page() on the page whenever the kernel reads and writes such a page - obviously that is too expensive for ALSA. Therefore, kernel architecture people need to trash this issue out, but I'm only interested in doing that post-2.6.4, once we've managed to get the DMA mapping stuff sorted properly. Unfortunately I'm busy for the next three days with other stuff, so I won't be able to look at any of this; I doubt 2.6.4 will be out before Friday morning anyway. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] buffer producer/consumer sync
On Tue, 9 Mar 2004, Russell King wrote: > On Tue, Mar 09, 2004 at 10:53:57AM +0100, Jaroslav Kysela wrote: > > On Tue, 9 Mar 2004, Gupta, Kshitij wrote: > > > > Can someone comment on this and guide a little bit to solve this problem. > > > > Yes, on ARM platform you might have problem with MMU / cache coherency, > > because appl_ptr and hw_ptr are mmaped to user space. I observed this > > behaviour on SA11xx platform, too. > > > > Russell King already notified us about this problem. See the mail archive > > for the proper fix of the midlevel code. > > There currently doesn't exist a public fix for this yet, so people using > ARM platforms will have to live without ALSA for the time being. > (Actually, you can still use ALSA but you must use OSS PCM emulation.) Ok, I though that vma->vm_page_prot fix is sufficient for this purpose but appearently not. Jaroslav - Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] buffer producer/consumer sync
hi, Just for your information we are using OSS PCM emulation. And let me also first understand the problem :). Which I am not able to figure out yet :(. regards -kshitij -Original Message- From: Russell King [mailto:[EMAIL PROTECTED] Behalf Of Russell King Sent: Tuesday, March 09, 2004 3:48 PM To: Jaroslav Kysela Cc: Gupta, Kshitij; [EMAIL PROTECTED] Subject: Re: [Alsa-devel] buffer producer/consumer sync On Tue, Mar 09, 2004 at 10:53:57AM +0100, Jaroslav Kysela wrote: > On Tue, 9 Mar 2004, Gupta, Kshitij wrote: > > > Can someone comment on this and guide a little bit to solve this problem. > > Yes, on ARM platform you might have problem with MMU / cache coherency, > because appl_ptr and hw_ptr are mmaped to user space. I observed this > behaviour on SA11xx platform, too. > > Russell King already notified us about this problem. See the mail archive > for the proper fix of the midlevel code. There currently doesn't exist a public fix for this yet, so people using ARM platforms will have to live without ALSA for the time being. (Actually, you can still use ALSA but you must use OSS PCM emulation.) As you say, appl_ptr and hw_ptr have cache coherency problems. However, a portable and acceptable solution does not exist today to solve this problem which would be acceptable to ALSA. The current preferred solution is to call flush_dcache_page() on the page whenever the kernel reads and writes such a page - obviously that is too expensive for ALSA. Therefore, kernel architecture people need to trash this issue out, but I'm only interested in doing that post-2.6.4, once we've managed to get the DMA mapping stuff sorted properly. Unfortunately I'm busy for the next three days with other stuff, so I won't be able to look at any of this; I doubt 2.6.4 will be out before Friday morning anyway. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] buffer producer/consumer sync
On Tue, Mar 09, 2004 at 11:23:45AM +0100, Jaroslav Kysela wrote: > Ok, I though that vma->vm_page_prot fix is sufficient for this purpose but > appearently not. Unfortunately not - as the code currently stands, not only are userspace mappings cached, but also kernel mappings of the same pages. Unfortunately changing userspace mappings to be uncached only solves half the problem. We also need to solve the kernel space problem as well. However, this needs to be done in an architecture specific way, which in turn means sorting out something which architecture people are happy with. Then there's the issue about the abuse of virt_to_page() taking a mapped virtual address (ie from pci_alloc_consistent or dma_alloc_coherent) rather than a direct-mapped virtual address (alloc_pages / kmalloc). -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] buffer producer/consumer sync
hi, I was referring to a ARM implementation in the ALSA tree for our ALSA driver development on OMAP 1610 (ARM 926) sound\arm\sa11xx-uda1341.c. Just wanted to know if sa11xx-uda1341.c is also affected by this problem. regards -kshitij -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gupta, Kshitij Sent: Tuesday, March 09, 2004 4:11 PM To: 'Russell King'; Jaroslav Kysela Cc: [EMAIL PROTECTED] Subject: RE: [Alsa-devel] buffer producer/consumer sync hi, Just for your information we are using OSS PCM emulation. And let me also first understand the problem :). Which I am not able to figure out yet :(. regards -kshitij -Original Message- From: Russell King [mailto:[EMAIL PROTECTED] Behalf Of Russell King Sent: Tuesday, March 09, 2004 3:48 PM To: Jaroslav Kysela Cc: Gupta, Kshitij; [EMAIL PROTECTED] Subject: Re: [Alsa-devel] buffer producer/consumer sync On Tue, Mar 09, 2004 at 10:53:57AM +0100, Jaroslav Kysela wrote: > On Tue, 9 Mar 2004, Gupta, Kshitij wrote: > > > Can someone comment on this and guide a little bit to solve this problem. > > Yes, on ARM platform you might have problem with MMU / cache coherency, > because appl_ptr and hw_ptr are mmaped to user space. I observed this > behaviour on SA11xx platform, too. > > Russell King already notified us about this problem. See the mail archive > for the proper fix of the midlevel code. There currently doesn't exist a public fix for this yet, so people using ARM platforms will have to live without ALSA for the time being. (Actually, you can still use ALSA but you must use OSS PCM emulation.) As you say, appl_ptr and hw_ptr have cache coherency problems. However, a portable and acceptable solution does not exist today to solve this problem which would be acceptable to ALSA. The current preferred solution is to call flush_dcache_page() on the page whenever the kernel reads and writes such a page - obviously that is too expensive for ALSA. Therefore, kernel architecture people need to trash this issue out, but I'm only interested in doing that post-2.6.4, once we've managed to get the DMA mapping stuff sorted properly. Unfortunately I'm busy for the next three days with other stuff, so I won't be able to look at any of this; I doubt 2.6.4 will be out before Friday morning anyway. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] buffer producer/consumer sync
On Tue, Mar 09, 2004 at 05:03:37PM +0530, Gupta, Kshitij wrote: > I was referring to a ARM implementation in the ALSA tree for our > ALSA driver development on OMAP 1610 (ARM 926) > sound\arm\sa11xx-uda1341.c. Just wanted to know if sa11xx-uda1341.c is also > affected by this problem. sa11xx-uda1341 isn't a good driver to look at - it's very specific to the iPAQ as it stands. I've been working on a properly modularised driver which separates out the PCM DMA engine from the rest of the code, which in turn makes it a lot easier to add support for different platforms. IOW, I've done the job properly. However, just as the iPAQ people (didn't) work with the rest of the ARM community when they created their supposed generic sa11xx-uda1341 implementation, the rest of the ARM community didn't work with them when creating our driver. And now various people are calling for sa11xx-uda1341 to be deleted once my driver is merged. It's good when communities fragment, isn't it? 8( However, the problem I've been describing is a problem with the core ALSA implementation and affects all hardware drivers on ARM, whether they be PCI, ISA or ARM specific. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] PCM hw mixing with volume
>And by that time, games will be even more demanding than before, and >still want to use those cycles for itself rather than software sound >processing, so just sitting idle waiting for the ultimate >infinite-megahertz cpu, that can do everything in no time, gains nobody >anything... at least our business won't. but don't you also want to be able to sell as many copies as possible to as many satisfied customers as possible? if so, you have to pay attention to whatever standards can be found for the domain at hand. in this case, the AC97 codec spec (and its recent successor whose name i forget) is about the most relevant thing i can think of. AFAIK, AC97 etc. say nothing about the kinds of gain control and mix routing that exist for multiple PCM streams. ergo, there is no standard way to do this that will work across a significant fraction of the installed and/or potential user base. so, either ALSA can come up with such a thing, which might be interesting but the manpower available to work on it is very limited, or parties that have a vested interest in it can use an existing API (SDL springs to mind, though i've never looked at it) or develop a new one that provides a standard mechanism for doing wat you want. i mean, even at the most basic level, the audio interface that is built into my laptop motherboard (some intel nonsense) cannot do any sample rate other than 48kHz! this is a high end laptop (HP Pavilion zd7000, 3GHz processor, 1440x900 display, etc) ... think of the cycles that will be spent *resampling* your audio independently of the mixing step. this type of BS seems to be growing more and more common. if i was in your position (specifically, if i have to assume that my user base spent a (comparatively) lot of money on a graphics card, maybe even paid for a 5.1 speaker setup, but are still using the factory-provided audio interface, i would assume the absolute worst capabilities for that interface that i could: single sample rate, single PCM stream, no mixer. and btw, i wasn't suggesting that you just "sit there waiting". my point was that the time you might spend working on this could be spent working on something else, and by the time you're done, CPU speed increases will have done this particular task for you. --p --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] PCM hw mixing with volume
At Tue, 09 Mar 2004 09:26:56 -0500, Paul Davis wrote: > > >And by that time, games will be even more demanding than before, and > >still want to use those cycles for itself rather than software sound > >processing, so just sitting idle waiting for the ultimate > >infinite-megahertz cpu, that can do everything in no time, gains nobody > >anything... at least our business won't. > > but don't you also want to be able to sell as many copies as possible > to as many satisfied customers as possible? if so, you have to pay > attention to whatever standards can be found for the domain at > hand. in this case, the AC97 codec spec (and its recent successor > whose name i forget) is about the most relevant thing i can think > of. AFAIK, AC97 etc. say nothing about the kinds of gain control and > mix routing that exist for multiple PCM streams. ergo, there is no > standard way to do this that will work across a significant fraction > of the installed and/or potential user base. BTW, the USB audio is another headache. the current ALSA PCM model isn't perfectly suitable for the devices like USB audio. (well, the current JACK implementation has the same problem, too ;) just an off-topic here, though... > so, either ALSA can come up with such a thing, which might be > interesting but the manpower available to work on it is very limited, > or parties that have a vested interest in it can use an existing API > (SDL springs to mind, though i've never looked at it) or develop a new > one that provides a standard mechanism for doing wat you want. > > i mean, even at the most basic level, the audio interface that is > built into my laptop motherboard (some intel nonsense) cannot do any > sample rate other than 48kHz! this is a high end laptop (HP Pavilion > zd7000, 3GHz processor, 1440x900 display, etc) ... think of the cycles > that will be spent *resampling* your audio independently of the mixing > step. this type of BS seems to be growing more and more common. if i > was in your position (specifically, if i have to assume that my user > base spent a (comparatively) lot of money on a graphics card, maybe > even paid for a 5.1 speaker setup, but are still using the > factory-provided audio interface, i would assume the absolute worst > capabilities for that interface that i could: single sample rate, > single PCM stream, no mixer. > > and btw, i wasn't suggesting that you just "sit there waiting". my > point was that the time you might spend working on this could be spent > working on something else, and by the time you're done, CPU speed > increases will have done this particular task for you. i guess that the special implementation for sb live! would be relatively easy once when the API is defined. it's nothing but a reduced version of PCM streams, so the h/w control is already in the driver. the most difficult part is the definition of the (somehow) generic but effective API. the same is true for 3D audio API. it'd be appreciated if app developers have a concrete wish list of API design about these stuffs, or even better a proposal of the API. Takashi --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Problems with Extigy mixer settings.
I would like to add that this patch has been tested by someone on #alsa
in irc.freenode.net and confirmed as a fix.
Please add this to the alsa cvs.
Cheers
James
Tommy Schultz Lassen wrote:
Hi
I have been having som problems with mixer settings on my Sound Blaster
Extigy.
I am using the alsa from the linux 2.6.3 kernel. White alsa's usbaudio.
When starting it wood fail. When i set #define IGNORE_CTL_ERROR in
usbmixer.c it wood load but when alsamixer came to the settings for the
digital In mixer port it wood start printing errors to the console.
This patch fixes it by disabling the mixer channel which gave the
problems.
Tommy
--- linux-2.6.3/sound/usb/usbmixer_maps.c 2004-02-25 18:22:10.0 +0100
+++ linux-2.6.3-usbaudio/sound/usb/usbmixer_maps.c 2004-02-26 21:32:54.0 +0100
@@ -86,6 +86,7 @@
{ 26, "IEC958 Optical Playback" }, /* OT */
{ 27, NULL }, /* DISABLED: EU (for what?) */
/* 28: FU speaker (mute) */
+ { 29, NULL /*"Digital In Playback Source"*/}, /* */
{ 0 } /* terminator */
};
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Problems with Extigy mixer settings.
At Tue, 09 Mar 2004 15:18:49 +, James Courtier-Dutton wrote: > > > I would like to add that this patch has been tested by someone on #alsa > in irc.freenode.net and confirmed as a fix. > > Please add this to the alsa cvs. now applied on cvs (together with another fix). Takashi --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Firewire 410
At 05 Mar 2004 11:23:35 +0100, Simon Schampijer wrote: > > Hello, > I've got a Maudio Firewire 410. > Are you going to make also drivers > for this one ? so far, no ALSA developer works on it. > Or are there Problems with > Maudio or firewire??? unfortunately, no hardware, no datasheet, no time... Takashi --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] PCM hw mixing with volume
tir, 09.03.2004 kl. 15.26 skrev Paul Davis: > >And by that time, games will be even more demanding than before, and > >still want to use those cycles for itself rather than software sound > >processing, so just sitting idle waiting for the ultimate > >infinite-megahertz cpu, that can do everything in no time, gains nobody > >anything... at least our business won't. > > but don't you also want to be able to sell as many copies as possible > to as many satisfied customers as possible? I suppose that's basically the idea. Customers want full support for their hardware. Which includes HW mixing. > if so, you have to pay > attention to whatever standards can be found for the domain at > hand. in this case, the AC97 codec spec (and its recent successor > whose name i forget) is about the most relevant thing i can think > of. AFAIK, AC97 etc. say nothing about the kinds of gain control and > mix routing that exist for multiple PCM streams. Yeah, we could consider AC97 to be a lowest common denominator. (That's not to say it is, since very old sound cards won't be compliant.) > ergo, there is no > standard way to do this that will work across a significant fraction > of the installed and/or potential user base. Are you mocking ALSA's plugin interface, too? Is there no "standard way" to play 22.050kHz streams using e.g. plughw? Or is plughw a design mistake? It can't be extended to use the route/volume plugin to adjust the volume of the stream in a "standard way", I suppose? > so, either ALSA can come up with such a thing, which might be > interesting but the manpower available to work on it is very limited, > or parties that have a vested interest in it can use an existing API > (SDL springs to mind, though i've never looked at it) or develop a new > one that provides a standard mechanism for doing wat you want. That's always going to be the case. It's Using Open Source In Business 101. > i mean, even at the most basic level, the audio interface that is > built into my laptop motherboard (some intel nonsense) cannot do any > sample rate other than 48kHz! this is a high end laptop (HP Pavilion > zd7000, 3GHz processor, 1440x900 display, etc) ... think of the cycles > that will be spent *resampling* your audio independently of the mixing > step. Independently? No, our software mixing code resamples, adjusts volume, and mixes the stream into the buffer in one step. That's one reason we've decided not to use ALSA's plugin system, as they do it in several steps (you'd have to run it through the rate plugin, the route/volume plugin, and finally the dmix plugin). For best performance, we resample on our own when the sound chip is locked to 48kHz (if we didn't, we might end up letting each sound go through *two* resampling steps - one from the sound effect's sample rate to the mixer stream's sample rate, and another from the mixer stream's rate to the sound card's physical rate if they don't match, therefore it's better to simply make the mixer stream's rate match the sound card's, so that each sound effect is resampled once and only once). > this type of BS seems to be growing more and more common. Perhaps they're thinking like you seem to, that the rise of CPU power will make hardware features obsolete. "Hardware has limitations, software don't." Same thing with winmodems. Why then do companies like Creative churn out sound cards with ever more powerful hardware features, if you're saying nobody should ever write code to take advantage of those hardware features? Since we're ranting anyway: It's a similar situation with 3D graphics hardware, where the 3D cards get ever more powerful, even though the CPU power is going up. And yet the OpenGL folks (at least those working on DRI) say "it's not important for the app to know whether something is done in hardware or not", which I have yet to make sense of given the trend. It's obvious that the greatest in-game 3D on the planet could not be done in smooth realtime on just a CPU without a GPU (particularly when the CPU is also supposed to control enemy AI, make 3D environmental effects on a 48kHz single-stream AC97 chip, communicate with other players via a winmodem, and so on), so why shouldn't there be a feature to tell that certain advanced 3D effects *could* be offloaded to hardware without getting more CPU load? > if i > was in your position (specifically, if i have to assume that my user > base spent a (comparatively) lot of money on a graphics card, maybe > even paid for a 5.1 speaker setup, but are still using the > factory-provided audio interface, i would assume the absolute worst > capabilities for that interface that i could: single sample rate, > single PCM stream, no mixer. Assumptions are seldom worth much. We're not going to assume anything here. If the card has sufficient hardware features, we wish to use them for what they're worth, since that's what they're there for. If it doesn't have them, then we obviously fall back to the old software mi
[Alsa-devel] USB audio devices
On Tue, 9 Mar 2004, Takashi Iwai wrote: > BTW, the USB audio is another headache. the current ALSA PCM model isn't > perfectly suitable for the devices like USB audio. Unfortunately I don't see a better model. We have already clear handshake, but USB 1.1 devices, and maybe the Linux core USB code, are failing to satisfy highly realtime needs, thus we need to manage the extra buffering to avoid underflows for the DMA operations. I don't know much about USB 2.0, but I guess that 1.x compatibility issues brings another overhead to this extension which makes it also unuseable when 1.x devices are connected to same USB port. I think that it's hardware design issue when the "extra delay" is counted, so we can hardly improve things. Jaroslav - Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Full support for Creamware Noah and SFP
Hi. As some of you may know, Creamware (http://www.creamware.de) is under new management since 2004 - and they have changed their mind regarding Linux support. Porting the SFP (Noah is part of SFP) to Linux is more than writing a mere driver, 'cause of the DSP based approach... It may be difficult to port the whole platform, but as an additional benefit (a huge one), all plugins and softsynths are already platform independent - porting the platform would give instant access to lots of high-quality plugins - they could be used on Linux as soon as the platform is ported (the plugins are encrypted archives containing the DSP code and the interface description, everything from the uplading to the interface drawing is handled by the SFP software). And the next version of the plugin IDE will be released for free anytime soon... But there is one problem: Creamware would open-source as much as possible and necessary to make SFP work, but not everything. I talked to Frank Hund of CW today, and he suggested a solution: They would give the specs and all sources to Linux developers under an NDA, to check what parts of the system would be needed to make the card work with ALSA (the basic soundcard features, and the bridge to use the SFP software). Those parts would be released under the GPL, and could become part of ALSA. The remaining parts of the platform (those needed to upload plugins to the DSP's) could be ported and provided binary only by Linux developers that signed the NDA, and may be provided for several architectures (x86, AMD64, PPC). Anyone interested in helping out (I'm not a coder, just a mere musician)? If there is interest, I will forward it to Frank. Ciao, -- Willie Sippel <[EMAIL PROTECTED]> [ z ] ! --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Firewire 410
>At 05 Mar 2004 11:23:35 +0100, >Simon Schampijer wrote: >> >> Hello, >> I've got a Maudio Firewire 410. >> Are you going to make also drivers >> for this one ? > >so far, no ALSA developer works on it. > >> Or are there Problems with >> Maudio or firewire??? > >unfortunately, no hardware, no datasheet, no time... when i talked with m-audio at NAMM, they claim that their firewire interface(s) will be "class compliant". on os-x, for example, there is no m-audio firewire driver, just one for the relevant standard for audio/midi over 1394. FWIW, Event/Echo and Apogee both said the same thing. whether this is strictly true is another matter, as is the question of how to get that standard in its full form. --p --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Firewire 410
Le mar 09/03/2004 Ã 19:32, Paul Davis a Ãcrit : > >At 05 Mar 2004 11:23:35 +0100, > >Simon Schampijer wrote: > >> > >> Hello, > >> I've got a Maudio Firewire 410. > >> Are you going to make also drivers > >> for this one ? > > > >so far, no ALSA developer works on it. > > > >> Or are there Problems with > >> Maudio or firewire??? > > > >unfortunately, no hardware, no datasheet, no time... > > when i talked with m-audio at NAMM, they claim that their firewire > interface(s) will be "class compliant". on os-x, for example, there is > no m-audio firewire driver, just one for the relevant standard for > audio/midi over 1394. FWIW, Event/Echo and Apogee both said the same > thing. > Hi, I have tried to use the m-audio with the iec61883 jack driver. After doing some test, I have found that I can have some noise only after an hot reboot of my powerbook (Mac OS X to Yellowdog Linux) with the card plugged. The strange thing is with hot reboot the card does not appear in /proc/bus/firewire (I haven't the laptop here to check). With a cold boot or an unplug/plug the card appears in /proc/bus/firewire but I haven't succesfully made any noise with this card. So perhaps there is a firmware uploading in Mac OS X like the RME Multiface. Tell me if you need more informations. Thanks a lot for your help, best regards, Simon. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] PCM hw mixing with volume
Hi, On Tue, 2004-03-09 at 13:25, Ove Kaaven wrote: > tir, 09.03.2004 kl. 15.26 skrev Paul Davis: > > >And by that time, games will be even more demanding than before, and > > >still want to use those cycles for itself rather than software sound > > >processing, so just sitting idle waiting for the ultimate > > >infinite-megahertz cpu, that can do everything in no time, gains nobody > > >anything... at least our business won't. > > > > but don't you also want to be able to sell as many copies as possible > > to as many satisfied customers as possible? > > I suppose that's basically the idea. Customers want full support for > their hardware. Which includes HW mixing. I agree. > > if so, you have to pay > > attention to whatever standards can be found for the domain at > > hand. in this case, the AC97 codec spec (and its recent successor > > whose name i forget) is about the most relevant thing i can think > > of. AFAIK, AC97 etc. say nothing about the kinds of gain control and > > mix routing that exist for multiple PCM streams. > > Yeah, we could consider AC97 to be a lowest common denominator. (That's > not to say it is, since very old sound cards won't be compliant.) AC97 means that you have at least one PCM stream. Nothing more than that. IMHO its pointless to say AC97 is a hardware capability. Its one way to accomplish a task that is common to any audio device. > > ergo, there is no > > standard way to do this that will work across a significant fraction > > of the installed and/or potential user base. > > Are you mocking ALSA's plugin interface, too? Is there no "standard way" > to play 22.050kHz streams using e.g. plughw? Or is plughw a design > mistake? It can't be extended to use the route/volume plugin to adjust > the volume of the stream in a "standard way", I suppose? I think it would be interesting to apply several effects at once. But it may be hard to come up with a clean design to accomplish that. > > so, either ALSA can come up with such a thing, which might be > > interesting but the manpower available to work on it is very limited, > > or parties that have a vested interest in it can use an existing API > > (SDL springs to mind, though i've never looked at it) or develop a new > > one that provides a standard mechanism for doing wat you want. > > That's always going to be the case. It's Using Open Source In Business > 101. AFAIK, OpenAL was developed for such purposes, but unfortunately its development is stuck. The Linux and MAC ports don't support any hardware features yet. BTW, i'm designing a control interface for ALSA for OpenAL (the current aureal driver, to be commited to public CVS in a few days, includes its first steps). > > i mean, even at the most basic level, the audio interface that is > > built into my laptop motherboard (some intel nonsense) cannot do any > > sample rate other than 48kHz! this is a high end laptop (HP Pavilion > > zd7000, 3GHz processor, 1440x900 display, etc) ... think of the cycles > > that will be spent *resampling* your audio independently of the mixing > > step. > > Independently? No, our software mixing code resamples, adjusts volume, > and mixes the stream into the buffer in one step. That's one reason > we've decided not to use ALSA's plugin system, as they do it in several > steps (you'd have to run it through the rate plugin, the route/volume > plugin, and finally the dmix plugin). For best performance, we resample > on our own when the sound chip is locked to 48kHz (if we didn't, we > might end up letting each sound go through *two* resampling steps - one > from the sound effect's sample rate to the mixer stream's sample rate, > and another from the mixer stream's rate to the sound card's physical > rate if they don't match, therefore it's better to simply make the mixer > stream's rate match the sound card's, so that each sound effect is > resampled once and only once). I agree. IMHO thats the most efficient way. Thats the way OpenAL handles such a case, but there is still a inconsistency, because the current OpenAL linux port -should- not provide software fallbacks, but it does anything in software (since there is still no hardware support), so it looks like software fallback will be provided inside the driver (ALSA). Since it can't (shouldn't) live in kernel context, i guess it would go into alsa-lib (plugin perhaps ?). > > this type of BS seems to be growing more and more common. > > Perhaps they're thinking like you seem to, that the rise of CPU power > will make hardware features obsolete. "Hardware has limitations, > software don't." Same thing with winmodems. Why then do companies like > Creative churn out sound cards with ever more powerful hardware > features, if you're saying nobody should ever write code to take > advantage of those hardware features? I own a 4 year old soundcard, which provides 16 very high quality 3D processor pipelines, and i still can't make use of it on any OS except win98. That definitely suck
[Alsa-devel] Fw: [Bug 76413] arts does not follow ALSA API
Might be of interest.. Begin forwarded message: Date: 3 Mar 2004 12:13:15 - From: Allan Sandfeld <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [Bug 76413] arts does not follow ALSA API --- You are receiving this mail because: --- You are a voter for the bug, or are watching someone who is. http://bugs.kde.org/show_bug.cgi?id=76413 --- Additional Comments From kde carewolf com 2004-03-03 13:13 --- We would be happy to accept your patches. I've started to work on this bug, but I know neither ALSA nor much of aRts. Currently the ALSA-plugin in aRts only calls snd_pcm_poll_descriptors, and uses the first returned fd there for later use in select. If I understand you correctly we need to be able to handle multiple file-descriptors, and can't be garantied that they have the right direction? Now how do we tell which of the returned descriptors are writefds and which are readfds? The only solution I can think of right now is to checks the revents and hope all the writable ones are already in a POLLOUT state. I am also worried about the ALSA-documentation which states the fds returned by snd_pcm_poll_descriotors might be bogus. -- to sign or not to sign, that is the question --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Full support for Creamware Noah and SFP
Hi Willie, Willie Sippel wrote: > Hi. > > As some of you may know, Creamware (http://www.creamware.de) is under > new management since 2004 - and they have changed their mind regarding > Linux support. Fine. [snipped interesting information about the SFP] I'm a user of the Creamware Noah (Ex). With extensive help from Clemens Ladisch we've got the audio and the midi interface working with the current alsa-cvs. (driver snd-usb-audio) I would really be amazed to have full Linux support for that device and I've some programming capabilities as well. But I'm not sure about, wether the NDA agrees in the basic alsa principles. What are the developers of alsa are thinking about that agreement? I'm working (for now only for my own requirements) on a midi based gui to control the different plugins. Without the possibilty to upload plugins so far. That's done by my one Windows machine. Ok, that doesn't happen that much. But it would be fine, to manage the CF-Card and other settings via the attached computer. The architecture that I'm able to provide is x86. Regards, Hartmut -- Hartmut Geissbauer <[EMAIL PROTECTED]> --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Firewire 410
On Tue, Mar 09, 2004 at 07:44:59 +0100, Simon Schampijer wrote: > I have tried to use the m-audio with the iec61883 jack driver. > After doing some test, I have found that I can have some noise only > after an hot reboot of my powerbook (Mac OS X to Yellowdog Linux) with > the card plugged. After talking with Bob, I think that he didnt even expect the iec61883 to be compatible with any hardware. It is in very early stages of development, and he has no hardware to test against. The initial aim was to get jack to jack communications working using something similar. - Steve --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Full support for Creamware Noah and SFP
> I would really be amazed to have full Linux support for that device and > I've some programming capabilities as well. > > But I'm not sure about, wether the NDA agrees in the basic alsa > principles. What are the developers of alsa are thinking about that > agreement? Hi Hartmut. I even wanted to contact you and Clemens off-list on this topic... I told Frank about the work you did on Noah support, and he was _very_ impressed. This even was one of the reasons he agreed on supporting Linux, given a capable programmer would join the show... Well, like I stated, the NDA would not really affect the driver, but the tool to upload the plugins. It's just that CW needs to know what parts of the current SFP solution are needed to provide basic support for the platform. That driver would be OSS and the necessary specs should be released, freely available to everyone without the need to sign a NDA. Check here: http://www.alsa-project.org/~cdavid/vendorinfo/call.html The NDA Creamware wants you to sign does not restrict the release of the sourcecode, so, everyone can access and modify the code - no problem with the GPL. It should work as follows: 1. Interested developers would sign the NDA. 2. Those developers would get the source and specs, and tell CW what parts need to become open to get the hardware working. 3. CW releases those informations, an ALSA driver would be written, enabling audio I/O and the control interface. 4. Interested developers would port the remaining parts of the SFP (the plugin handler), to be released closed-source. And, as you may know, the Luna/ Pulsar/ Powersampler cards are also part of the SFP, and those cards are completely worthless for a Linux DAW right now. And you wouldn't need to create your own control tool anymore, 'cause the interface is already part of the .dev file - it uses an interface description language similar to JavaScript for platform independence... I could bug-test the driver for Powersampler, and provide x86 and AMD64 binaries - PPC, anyone...? ;-) Ciao, -- Willie Sippel <[EMAIL PROTECTED]> [ z ] ! --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
