[Alsa-devel] buffer producer/consumer sync

2004-03-09 Thread Gupta, Kshitij
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

2004-03-09 Thread Jaroslav Kysela
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=1470alloc_id=3638op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


Re: [Alsa-devel] buffer producer/consumer sync

2004-03-09 Thread Jaroslav Kysela
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=1470alloc_id=3638op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


RE: [Alsa-devel] buffer producer/consumer sync

2004-03-09 Thread Gupta, Kshitij
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=1470alloc_id=3638op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


RE: [Alsa-devel] buffer producer/consumer sync

2004-03-09 Thread Gupta, Kshitij
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=1470alloc_id=3638op=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=1470alloc_id=3638op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


Re: [Alsa-devel] PCM hw mixing with volume

2004-03-09 Thread 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? 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=1470alloc_id=3638op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


Re: [Alsa-devel] PCM hw mixing with volume

2004-03-09 Thread Takashi Iwai
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=1470alloc_id=3638op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


[Alsa-devel] Fw: [Bug 76413] arts does not follow ALSA API

2004-03-09 Thread Florian Schmidt

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=1470alloc_id=3638op=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

2004-03-09 Thread Hartmut Geissbauer
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=1470alloc_id=3638op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel


Re: [Alsa-devel] Firewire 410

2004-03-09 Thread Steve Harris
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=1470alloc_id=3638op=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

2004-03-09 Thread Willie Sippel
 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=1470alloc_id=3638op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel