PCM driver only plays tiny portion of clip

PCM driver only plays tiny portion of clip

[Adrian McMenamin]

My driver (for sound on the Sega Dreamcast) will now play the first part
of a pcm sound – eg if I do the following:

cat hal.wav > /dev/dsp

I get the “I’m sorry” bit of “I’m sorry Dave I can’t do that” – I am using
the oss emulation because I cannot get aplay to work on my system.

The clip however is stuck in an endless loop (in a sense this is the
expected behaviour – the sound system on the dreamcast normally loops over
its buffer until told to do otherwise) and most of the “playback” is
silence.

As the DMA transfer to the sound memory is working, it looks like the
first 32k (or maybe just 4k – the period size) of the clip is transferred
but nothing else.

How do I let my driver know that it has played a period and therefore it
needs to load more into the buffer?

At the moment the following seems to be happening:

Create buffer in DMA space in main CPU addressed area
    |
    |
Transfer contents of buffer into memory space of sound chip via DMA
    |
    |
Start playback
    |
    |
Fire interrupt for period played


Then it gets stuck in a loop – the interrupt is fired and handled but
nothing else seems to happen.

I’m a bit stuck and this might not be very clear, but any clues?




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642

Re: PCM driver only plays tiny portion of clip

[Clemens Ladisch]

Adrian McMenamin wrote:
> How do I let my driver know that it has played a period and therefore it
> needs to load more into the buffer?
> 
> At the moment the following seems to be happening:
> 
> Create buffer in DMA space in main CPU addressed area
>     |
>     |
> Transfer contents of buffer into memory space of sound chip via DMA
>     |
>     |
> Start playback
>     |
>     |
> Fire interrupt for period played
> 
> Then it gets stuck in a loop ? the interrupt is fired and handled but
> nothing else seems to happen.

ALSA will notice that something has been played when the return value of
the pointer callback changes.

What are the contents of /proc/asound/card0/pcm0p/sub0/* while it's
playing?


Regards,
Clemens


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Adrian McMenamin]

On Mon, 27 February, 2006 5:26 pm, Clemens Ladisch wrote:
> Adrian McMenamin wrote:
>> How do I let my driver know that it has played a period and therefore it
>> needs to load more into the buffer?
>>
>> At the moment the following seems to be happening:
>>
>> Create buffer in DMA space in main CPU addressed area
>>     |
>>     |
>> Transfer contents of buffer into memory space of sound chip via DMA
>>     |
>>     |
>> Start playback
>>     |
>>     |
>> Fire interrupt for period played
>>
>> Then it gets stuck in a loop ? the interrupt is fired and handled but
>> nothing else seems to happen.
>
> ALSA will notice that something has been played when the return value of
> the pointer callback changes.
>
And what happens then? ie what will the alsa subsystem do when that
changes (as it certainly will be duting the playback as it cycles through
the buffer)


> What are the contents of /proc/asound/card0/pcm0p/sub0/* while it's
> playing?
>

Cannot tell because the system is locked - ie it's repeatedly playing the
sound. I'll have to see if I can get dropbear to work (the console is
accessed over a serial line atm)


>
> Regards,
> Clemens
>




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642

Re: PCM driver only plays tiny portion of clip

[Clemens Ladisch]

Adrian McMenamin wrote:
> On Mon, 27 February, 2006 5:26 pm, Clemens Ladisch wrote:
> > ALSA will notice that something has been played when the return value of
> > the pointer callback changes.
> 
> And what happens then? ie what will the alsa subsystem do when that
> changes (as it certainly will be duting the playback as it cycles through
> the buffer)

When an interrupt occurs (that is, when it calls
snd_pcm_period_elapsed()), ALSA calls the pointer callback.  A different
return value indicates that there is some free space in the buffer, so
ALSA wakes up the application so that it can write more data.


HTH
Clemens


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Adrian McMenamin]

On Tue, 28 February, 2006 7:30 am, Clemens Ladisch wrote:
> Adrian McMenamin wrote:
>> On Mon, 27 February, 2006 5:26 pm, Clemens Ladisch wrote:
>> > ALSA will notice that something has been played when the return value
>> of
>> > the pointer callback changes.
>>
>> And what happens then? ie what will the alsa subsystem do when that
>> changes (as it certainly will be duting the playback as it cycles
>> through
>> the buffer)
>
> When an interrupt occurs (that is, when it calls
> snd_pcm_period_elapsed()), ALSA calls the pointer callback.  A different
> return value indicates that there is some free space in the buffer, so
> ALSA wakes up the application so that it can write more data.
>
>

This (application writing more data) doesn't seem to be happening in my case.

I am using oss emulation and a simple car command ie cat somefile.wav >
/dev/dsp - should I expect this to work, or do I really need to compile
something like sox (does sox use the native alsa if)?



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642

Re: PCM driver only plays tiny portion of clip

[Clemens Ladisch]

Adrian McMenamin wrote:
> On Tue, 28 February, 2006 7:30 am, Clemens Ladisch wrote:
> > When an interrupt occurs (that is, when it calls
> > snd_pcm_period_elapsed()), ALSA calls the pointer callback.  A different
> > return value indicates that there is some free space in the buffer, so
> > ALSA wakes up the application so that it can write more data.
> 
> This (application writing more data) doesn't seem to be happening in my case.
> 
> I am using oss emulation and a simple car command ie cat somefile.wav >
> /dev/dsp - should I expect this to work, or do I really need to compile
> something like sox (does sox use the native alsa if)?

Dumping something into /dev/dsp should work.  It may use the wrong
sample format, but if the first part of the file can be heard, the rest
should play OK, too.


HTH
Clemens


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Adrian McMenamin]

On Tue, 28 February, 2006 2:55 pm, Clemens Ladisch wrote:
> Adrian McMenamin wrote:
>> On Tue, 28 February, 2006 7:30 am, Clemens Ladisch wrote:
>> > When an interrupt occurs (that is, when it calls
>> > snd_pcm_period_elapsed()), ALSA calls the pointer callback.  A
>> different
>> > return value indicates that there is some free space in the buffer, so
>> > ALSA wakes up the application so that it can write more data.
>>
>> This (application writing more data) doesn't seem to be happening in my
>> case.
>>
>> I am using oss emulation and a simple car command ie cat somefile.wav >
>> /dev/dsp - should I expect this to work, or do I really need to compile
>> something like sox (does sox use the native alsa if)?
>
> Dumping something into /dev/dsp should work.  It may use the wrong
> sample format, but if the first part of the file can be heard, the rest
> should play OK, too.
>
Thanks

I am at something of a loss though.

I admit that my dma code as it is today won't work properly - the dma
transfer function tries to fill the whole of the ring buffer everytime it
is called. But it is only being called once - which is the real problem! I
can fix the dma issue I am sure, but it is not the blockage at the moment.

When the pointer callback returned incorrect values the dma function did
get called more than once and the sample was all tranferred, if in a
useless way. But now it sends the correct value (and I've tested it as
such)such) it doesn't and the playback is stuck in an endless loop merely
playing the first part of the sample.

I'm at something of a loss as to know what to do



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642

Re: PCM driver only plays tiny portion of clip

[Clemens Ladisch]

Adrian McMenamin wrote:
> On Tue, 28 February, 2006 2:55 pm, Clemens Ladisch wrote:
> > Dumping something into /dev/dsp should work.  It may use the wrong
> > sample format, but if the first part of the file can be heard, the rest
> > should play OK, too.
> 
> I am at something of a loss though.
> 
> I admit that my dma code as it is today won't work properly - the dma
> transfer function tries to fill the whole of the ring buffer everytime it
> is called. But it is only being called once - which is the real problem! I
> can fix the dma issue I am sure, but it is not the blockage at the moment.

Where is the source code of your driver?


Regards,
Clemens


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Adrian McMenamin]

On Tue, 28 February, 2006 5:08 pm, Clemens Ladisch wrote:

>
> Where is the source code of your driver?
>
>

http://newgolddream.dyndns.info/repos




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642

Re: PCM driver only plays tiny portion of clip

[Adrian McMenamin]

On Tue, 2006-02-28 at 17:36 +0000, Adrian McMenamin wrote:
> On Tue, 28 February, 2006 5:08 pm, Clemens Ladisch wrote:
> 
> >
> > Where is the source code of your driver?
> >
> >
> 
> http://newgolddream.dyndns.info/repos
> 
Anybody have any comments? For my own understanding is the patten this:

Hardware triggers interrupt as period boundary passed  ---->

Interrupt handler calls ALSA middle layer  ---->

ALSA middle layer calls pointer callback --->

Pointer callback returns ring buffer position


What happens next?



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Lee Revell]

On Wed, 2006-03-01 at 19:10 +0000, Adrian McMenamin wrote:
> On Tue, 2006-02-28 at 17:36 +0000, Adrian McMenamin wrote:
> > On Tue, 28 February, 2006 5:08 pm, Clemens Ladisch wrote:
> > 
> > >
> > > Where is the source code of your driver?
> > >
> > >
> > 
> > http://newgolddream.dyndns.info/repos
> > 
> Anybody have any comments? For my own understanding is the patten this:
> 
> Hardware triggers interrupt as period boundary passed  ---->
> 
> Interrupt handler calls ALSA middle layer  ---->
> 
> ALSA middle layer calls pointer callback --->
> 
> Pointer callback returns ring buffer position
> 
> 
> What happens next?

The app(s) waiting to output audio (sleeping in poll() or write()) will
be woken up and based on the value returned by the pointer callback
above, informed that there is space in the buffer and how much space
there is, and will then write the next chunk of frames, and go back to
sleep.  Then we go back to "Hardware triggers interrupt" above and the
process repeats.

I'm not sure why your driver is locking up the system - maybe the
pointer callback indicates that there is more space in the buffer than
there is, which might wedge the app when it goes to write the next
period of audio?  But normally this would just cause corrupted sound,
not a lockup...

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Adrian McMenamin]

On Wed, 2006-03-01 at 14:31 -0500, Lee Revell wrote:

> > What happens next?
> 
> The app(s) waiting to output audio (sleeping in poll() or write()) will
> be woken up and based on the value returned by the pointer callback
> above, informed that there is space in the buffer and how much space
> there is, and will then write the next chunk of frames, and go back to
> sleep.  Then we go back to "Hardware triggers interrupt" above and the
> process repeats.

But something in the alsa subsystem determines whether there is any
space before waking the app, yes?

and when the app is woken alsa calls the trigger callback?



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Lee Revell]

On Wed, 2006-03-01 at 19:40 +0000, Adrian McMenamin wrote:
> On Wed, 2006-03-01 at 14:31 -0500, Lee Revell wrote:
> 
> > > What happens next?
> > 
> > The app(s) waiting to output audio (sleeping in poll() or write()) will
> > be woken up and based on the value returned by the pointer callback
> > above, informed that there is space in the buffer and how much space
> > there is, and will then write the next chunk of frames, and go back to
> > sleep.  Then we go back to "Hardware triggers interrupt" above and the
> > process repeats.
> 
> But something in the alsa subsystem determines whether there is any
> space before waking the app, yes?
> 

Yes - the value returned by your pointer callback minus the last value
returned by your pointer callback determines how much space is left.  So
if the app is waiting to write 512 frames, the pointer was 256 at the
last interrupt, and the current pointer is 512, the app will not wake up
until the next interrupt because only 256 frames can be written.

> and when the app is woken alsa calls the trigger callback?
> 

No when the app is woken it writes the data to the buffer, and we're
done, until the next interrupt.

The trigger callback is only called when the PCM is stopped, started, or
paused.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Adrian McMenamin]

On Wed, 2006-03-01 at 14:59 -0500, Lee Revell wrote:

> 
> The trigger callback is only called when the PCM is stopped, started, or
> paused.
> 


Which buffer?



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Lee Revell]

On Wed, 2006-03-01 at 20:20 +0000, Adrian McMenamin wrote:
> On Wed, 2006-03-01 at 14:59 -0500, Lee Revell wrote:
> 
> > 
> > The trigger callback is only called when the PCM is stopped, started, or
> > paused.
> > 
> 
> 
> Which buffer?

The way most soundcards work is that there is a single ring buffer
shared by the software and hardware.  Once the PCM is started the
hardware will repeatedly loop over this buffer playing the samples in
it.  The buffer is normally divided in half - while your app is writing
to one half of the buffer the hardware is playing the samples in the
other half.  The hardware generates interrupts at the middle and end of
this buffer, which is where we switch - the hardware is now playing what
the software just wrote to the one half of the buffer and the software
can write into the other half that was just played by the hardware.

If your soundcard does not work this way you'll have to model it
somehow.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Adrian McMenamin]

On Wed, 2006-03-01 at 14:59 -0500, Lee Revell wrote:
> On Wed, 2006-03-01 at 19:40 +0000, Adrian McMenamin wrote:
> > On Wed, 2006-03-01 at 14:31 -0500, Lee Revell wrote:
> > 
> > > > What happens next?
> > > 
> > > The app(s) waiting to output audio (sleeping in poll() or write()) will
> > > be woken up and based on the value returned by the pointer callback
> > > above, informed that there is space in the buffer and how much space
> > > there is, and will then write the next chunk of frames, and go back to
> > > sleep.  Then we go back to "Hardware triggers interrupt" above and the
> > > process repeats.
> > 
> > But something in the alsa subsystem determines whether there is any
> > space before waking the app, yes?
> > 
> 
> Yes - the value returned by your pointer callback minus the last value
> returned by your pointer callback determines how much space is left.  So
> if the app is waiting to write 512 frames, the pointer was 256 at the
> last interrupt, and the current pointer is 512, the app will not wake up
> until the next interrupt because only 256 frames can be written.
> 

Presumably this is on the assumption that 512 frames is a period?





-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Lee Revell]

On Wed, 2006-03-01 at 20:28 +0000, Adrian McMenamin wrote:
> On Wed, 2006-03-01 at 14:59 -0500, Lee Revell wrote:
> > On Wed, 2006-03-01 at 19:40 +0000, Adrian McMenamin wrote:
> > > On Wed, 2006-03-01 at 14:31 -0500, Lee Revell wrote:
> > > 
> > > > > What happens next?
> > > > 
> > > > The app(s) waiting to output audio (sleeping in poll() or write()) will
> > > > be woken up and based on the value returned by the pointer callback
> > > > above, informed that there is space in the buffer and how much space
> > > > there is, and will then write the next chunk of frames, and go back to
> > > > sleep.  Then we go back to "Hardware triggers interrupt" above and the
> > > > process repeats.
> > > 
> > > But something in the alsa subsystem determines whether there is any
> > > space before waking the app, yes?
> > > 
> > 
> > Yes - the value returned by your pointer callback minus the last value
> > returned by your pointer callback determines how much space is left.  So
> > if the app is waiting to write 512 frames, the pointer was 256 at the
> > last interrupt, and the current pointer is 512, the app will not wake up
> > until the next interrupt because only 256 frames can be written.
> > 
> 
> Presumably this is on the assumption that 512 frames is a period?

In this example the period (# of frames between interrupts) is 256.  So
if the app is waiting to write 512 frames (by setting the avail_min
software parameter) it will be woken up every other interrupt.  (This
example only makes sense if there are more than 2 periods per buffer,
otherwise the app is constantly overwriting the data that the hardware
is playing).

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Adrian McMenamin]

On Wed, 2006-03-01 at 15:41 -0500, Lee Revell wrote:

> 
> In this example the period (# of frames between interrupts) is 256.  So
> if the app is waiting to write 512 frames (by setting the avail_min
> software parameter) it will be woken up every other interrupt.  (This
> example only makes sense if there are more than 2 periods per buffer,
> otherwise the app is constantly overwriting the data that the hardware
> is playing).
> 
> Lee


I think I have a good idea why my it is not working now - the DMA
routine which transfers sound samples from the main CPU memory to the
ring buffer of the hardware (which is effectively in a different memory
space) is in a kernel thread which, in essence, never gets rescheduled -
so the app thinks there is sound to be transferred but it never is -
hence it gets wedged.

To fix that I need to know what the alsa subsystem calls inside the
driver when it wants a DMA transfer to resume - I have to reschedule the
kernel thread there.

(I have to use a kernel thread or at least something similar to ensure
that the trigger callback remains atomic due to the nature of the SH
DMAC API.)



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Clemens Ladisch]

Adrian McMenamin wrote:
> I think I have a good idea why my it is not working now - the DMA
> routine which transfers sound samples from the main CPU memory to the
> ring buffer of the hardware (which is effectively in a different memory
> space) is in a kernel thread which, in essence, never gets rescheduled -
> so the app thinks there is sound to be transferred but it never is -
> hence it gets wedged.
> 
> To fix that I need to know what the alsa subsystem calls inside the
> driver when it wants a DMA transfer to resume - I have to reschedule the
> kernel thread there.

ALSA doesn't call the driver.  It assumes the hardware runs by itself.

If your hardware doesn't issue some interrupt regularly, you have to use
a timer.


HTH
Clemens


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Adrian McMenamin]

On Fri, 2006-03-03 at 08:27 +0100, Clemens Ladisch wrote:
> Adrian McMenamin wrote:
> > I think I have a good idea why my it is not working now - the DMA
> > routine which transfers sound samples from the main CPU memory to the
> > ring buffer of the hardware (which is effectively in a different memory
> > space) is in a kernel thread which, in essence, never gets rescheduled -
> > so the app thinks there is sound to be transferred but it never is -
> > hence it gets wedged.
> > 
> > To fix that I need to know what the alsa subsystem calls inside the
> > driver when it wants a DMA transfer to resume - I have to reschedule the
> > kernel thread there.
> 
> ALSA doesn't call the driver.  It assumes the hardware runs by itself.
> 
> If your hardware doesn't issue some interrupt regularly, you have to use
> a timer.
> 
It does have an interrupt - I am working on the idea of having the
kernel thread sleep and then wake up on the interrupt



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Lee Revell]

On Fri, 2006-03-03 at 07:42 +0000, Adrian McMenamin wrote:
> On Fri, 2006-03-03 at 08:27 +0100, Clemens Ladisch wrote:
> > Adrian McMenamin wrote:
> > > I think I have a good idea why my it is not working now - the DMA
> > > routine which transfers sound samples from the main CPU memory to the
> > > ring buffer of the hardware (which is effectively in a different memory
> > > space) is in a kernel thread which, in essence, never gets rescheduled -
> > > so the app thinks there is sound to be transferred but it never is -
> > > hence it gets wedged.
> > > 
> > > To fix that I need to know what the alsa subsystem calls inside the
> > > driver when it wants a DMA transfer to resume - I have to reschedule the
> > > kernel thread there.
> > 
> > ALSA doesn't call the driver.  It assumes the hardware runs by itself.
> > 
> > If your hardware doesn't issue some interrupt regularly, you have to use
> > a timer.
> > 
> It does have an interrupt - I am working on the idea of having the
> kernel thread sleep and then wake up on the interrupt

Why do you need the thread at all - can't you just do that work in the
interrupt handler?

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Lee Revell]

On Fri, 2006-03-03 at 08:17 +0000, Adrian McMenamin wrote:
> I need a thread because the SH DMAC routine that does the DMA handling
> is not atomic and therefore cannot be started from the trigger
> callback.
> The idea is that the interrupt handler reschedules the worker thread
> which is sleeping in an endless loop... something is very wrong with
> it
> all at the moment though as it causes kernel panics 

Actually this raises an interesting question - if the hardware has no
real DMA and must rely on the copy/silence callbacks to transfer the
data, what should be done in the trigger callback when the PCM is
started?

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Lee Revell]

On Fri, 2006-03-03 at 07:42 +0000, Adrian McMenamin wrote:
> On Fri, 2006-03-03 at 08:27 +0100, Clemens Ladisch wrote:
> > Adrian McMenamin wrote:
> > > I think I have a good idea why my it is not working now - the DMA
> > > routine which transfers sound samples from the main CPU memory to the
> > > ring buffer of the hardware (which is effectively in a different memory
> > > space) is in a kernel thread which, in essence, never gets rescheduled -
> > > so the app thinks there is sound to be transferred but it never is -
> > > hence it gets wedged.
> > > 
> > > To fix that I need to know what the alsa subsystem calls inside the
> > > driver when it wants a DMA transfer to resume - I have to reschedule the
> > > kernel thread there.
> > 
> > ALSA doesn't call the driver.  It assumes the hardware runs by itself.
> > 
> > If your hardware doesn't issue some interrupt regularly, you have to use
> > a timer.
> > 
> It does have an interrupt - I am working on the idea of having the
> kernel thread sleep and then wake up on the interrupt
> 

Hmm, maybe the work should be done in the copy callback:

copy and silence callbacks
These callbacks are not mandatory, and can be omitted in most cases.
These callbacks are used when the hardware buffer cannot be on the
normal memory space. Some chips have their own buffer on the hardware
which is not mappable. In such a case, you have to transfer the data
manually from the memory buffer to the hardware buffer. Or, if the
buffer is non-contiguous on both physical and virtual memory spaces,
these callbacks must be defined, too. 

If these two callbacks are defined, copy and set-silence operations are
done by them. The detailed will be described in the later section Buffer
and Memory Management. 

http://www.alsa-project.org/~iwai/writing-an-alsa-driver/x639.htm#PCM-INTERFACE-OPERATORS-COPY-SILENCE

Lee






-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Lee Revell]

On Fri, 2006-03-03 at 07:42 +0000, Adrian McMenamin wrote:
> On Fri, 2006-03-03 at 08:27 +0100, Clemens Ladisch wrote:
> > Adrian McMenamin wrote:
> > > I think I have a good idea why my it is not working now - the DMA
> > > routine which transfers sound samples from the main CPU memory to the
> > > ring buffer of the hardware (which is effectively in a different memory
> > > space) is in a kernel thread which, in essence, never gets rescheduled -
> > > so the app thinks there is sound to be transferred but it never is -
> > > hence it gets wedged.
> > > 
> > > To fix that I need to know what the alsa subsystem calls inside the
> > > driver when it wants a DMA transfer to resume - I have to reschedule the
> > > kernel thread there.
> > 
> > ALSA doesn't call the driver.  It assumes the hardware runs by itself.
> > 
> > If your hardware doesn't issue some interrupt regularly, you have to use
> > a timer.
> > 
> It does have an interrupt - I am working on the idea of having the
> kernel thread sleep and then wake up on the interrupt
> 

Also see

http://www.alsa-project.org/~iwai/writing-an-alsa-driver/x1401.htm

External Hardware Buffers
Some chips have their own hardware buffers and the DMA transfer from the
host memory is not available. In such a case, you need to either 1)
copy/set the audio data directly to the external hardware buffer, or 2)
make an intermediate buffer and copy/set the data from it to the
external hardware buffer in interrupts (or in tasklets, preferably). 

Doesn't this describe your hardware exactly?

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Adrian McMenamin]

On Wed, 2006-03-01 at 14:31 -0500, Lee Revell wrote:


> 
> I'm not sure why your driver is locking up the system - maybe the
> pointer callback indicates that there is more space in the buffer than
> there is, which might wedge the app when it goes to write the next
> period of audio?  But normally this would just cause corrupted sound,
> not a lockup...
> 

I know it never reschedules the thread that does the dma transfer (I had
to use a kernel thread to keep the trigger call atomic).

It seems to me the issue is that the alsa middle layer never thinks
there is any space - possibly because my ring buffer and the dma buffer
are the same size?



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: PCM driver only plays tiny portion of clip

[Adrian McMenamin]

On Mon, 2006-02-27 at 18:26 +0100, Clemens Ladisch wrote:

> 
> ALSA will notice that something has been played when the return value of
> the pointer callback changes.
> 

Testing shows that it does change...

ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x23
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x4B
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x73
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0xAF
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0xD7
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0xFF
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x13B
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x163
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x18B
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x1C6
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x1EE
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x216
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x252
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x27A
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x2A2
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x2DE
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x306
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x32E
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x369
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x391
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x3B9
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x3F5
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x41D
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x445
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x481
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x4A9
ALSA /home/adrian/aica/aica/snd_card_aica.c:363: Value is 0x4D1


etc - cycling onwards to the end of the buffer and then repeating...



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642