Re: kernel threads etc

Re: kernel threads etc

[Lee Revell]

On Mon, 2006-03-06 at 22:27 +0000, Adrian McMenamin wrote:
> I have an interrupt handler in my sound driver that calls this:

You never explained why you want to create a kernel thread rather than
implementing copy/silence callbacks like the docs say.

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: kernel threads etc

[Adrian McMenamin]

On Mon, 2006-03-06 at 18:11 -0500, Lee Revell wrote:
> On Mon, 2006-03-06 at 22:27 +0000, Adrian McMenamin wrote:
> > I have an interrupt handler in my sound driver that calls this:
> 
> You never explained why you want to create a kernel thread rather than
> implementing copy/silence callbacks like the docs say.
> 
> Lee

Because what the documents actually say is: "Some chips have their own
hardware buffers and the DMA transfer from the host memory is not
available."

Well, DMA is very much available. Though I can see that: "Another case
is that the chip uses a PCI memory-map region for the buffer" could be
similar.



-------------------------------------------------------
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: kernel threads etc

[Adrian McMenamin]

On Mon, 2006-03-06 at 18:11 -0500, Lee Revell wrote:
> On Mon, 2006-03-06 at 22:27 +0000, Adrian McMenamin wrote:
> > I have an interrupt handler in my sound driver that calls this:
> 
> You never explained why you want to create a kernel thread rather than
> implementing copy/silence callbacks like the docs say.
> 
> Lee

Reading through the notes it states:

"The third argument (pos) points the current position offset in frames."

Presumably that means the position in the playback ring buffer? It's not
at all clear. 




-------------------------------------------------------
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: kernel threads etc

[Lee Revell]

On Mon, 2006-03-06 at 23:29 +0000, Adrian McMenamin wrote:
> On Mon, 2006-03-06 at 18:11 -0500, Lee Revell wrote:
> > On Mon, 2006-03-06 at 22:27 +0000, Adrian McMenamin wrote:
> > > I have an interrupt handler in my sound driver that calls this:
> > 
> > You never explained why you want to create a kernel thread rather than
> > implementing copy/silence callbacks like the docs say.
> > 
> > Lee
> 
> Because what the documents actually say is: "Some chips have their own
> hardware buffers and the DMA transfer from the host memory is not
> available."
> 
> Well, DMA is very much available. Though I can see that: "Another case
> is that the chip uses a PCI memory-map region for the buffer" could be
> similar.
> 

Sorry, I guess I'm still not getting it.

You say things like this:

"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."

What exactly is this "DMA function" doing?  If you have to write a
function to transfer the samples from host memory to the device - how is
that DMA?

When I think of soundcard DMA I mean that you tell the card where in
host memory the buffer is, then to start the DMA, and from then on,
until you stop it, the device will automatically write audio into that
area of host memory until you tell it to stop.

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: kernel threads etc

[Adrian McMenamin]

On Mon, 2006-03-06 at 18:48 -0500, Lee Revell wrote:
> On Mon, 2006-03-06 at 23:29 +0000, Adrian McMenamin wrote:
> > On Mon, 2006-03-06 at 18:11 -0500, Lee Revell wrote:
> > > On Mon, 2006-03-06 at 22:27 +0000, Adrian McMenamin wrote:
> > > > I have an interrupt handler in my sound driver that calls this:
> > > 
> > > You never explained why you want to create a kernel thread rather than
> > > implementing copy/silence callbacks like the docs say.
> > > 
> > > Lee
> > 
> > Because what the documents actually say is: "Some chips have their own
> > hardware buffers and the DMA transfer from the host memory is not
> > available."
> > 
> > Well, DMA is very much available. Though I can see that: "Another case
> > is that the chip uses a PCI memory-map region for the buffer" could be
> > similar.
> > 
> 
> Sorry, I guess I'm still not getting it.
> 
> You say things like this:
> 
> "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."
> 

Thanks to yours and others help I had really moved on from the above!



> What exactly is this "DMA function" doing?  If you have to write a
> function to transfer the samples from host memory to the device - how is
> that DMA?
> 

It transfers - without CPU intervention - memory from the SH4 (main CPU)
memory to the ARM7 (sound processing chip) memory (ie the playback ring
buffer). The function simply sets the register values and off it goes


> When I think of soundcard DMA I mean that you tell the card where in
> host memory the buffer is, then to start the DMA, and from then on,
> until you stop it, the device will automatically write audio into that
> area of host memory until you tell it to stop.
> 
By buffer you mean the sound card buffer? I don't have that luxury I'm
afraid. I've got real dma though, just not of that kind.

I am trying the copy method now, which looks as though it might be
simpler - but the src needs to be 32 byte aligned and just isn't :(



-------------------------------------------------------
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: kernel threads etc

[Lee Revell]

On Tue, 2006-03-07 at 00:11 +0000, Adrian McMenamin wrote:
> It transfers - without CPU intervention - memory from the SH4 (main
> CPU)
> memory to the ARM7 (sound processing chip) memory (ie the playback
> ring
> buffer). The function simply sets the register values and off it goes
> 
> 

OK - so it's the same DMA I am familiar with, it just needs to be
reprogrammed every period - IOW you can't tell it "repeatedly transfer
audio to this location until I tell you to stop".

If this is the case then I would say forget about the kernel thread and
the copy/silence callbacks - just do all the 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: kernel threads etc

[Adrian McMenamin]

On Mon, 2006-03-06 at 19:22 -0500, Lee Revell wrote:
> On Tue, 2006-03-07 at 00:11 +0000, Adrian McMenamin wrote:
> > It transfers - without CPU intervention - memory from the SH4 (main
> > CPU)
> > memory to the ARM7 (sound processing chip) memory (ie the playback
> > ring
> > buffer). The function simply sets the register values and off it goes
> > 
> > 
> 
> OK - so it's the same DMA I am familiar with, it just needs to be
> reprogrammed every period - IOW you can't tell it "repeatedly transfer
> audio to this location until I tell you to stop".
> 
> If this is the case then I would say forget about the kernel thread and
> the copy/silence callbacks - just do all the work in the interrupt
> handler.
> 
OK. I am doing this (dealing with it in the interrupt handler) and so
far it seems to work quite well, though it is still stuck in an endless
loop, but I have a fair idea why, but i'm not sure how to deal with it.

Right now this is what happens:

0. Create a DMA buffer in SH4 space - this is used as the source for the
dma transfer (the target is in the ARM7's memory space). Alsa seems to
fill up this buffer easily enough

1. Fill the ring buffer completely with first DMA transfer (ring buffer
has space for 8 periods) on receiving the SNDDRV_PCM_TRIGGER_START, then
start the ARM7 playback

2. ARM7 fires interrupt on SH4 bus every time period is played

3. SH4 interrupt handler counts interrupts - have 4 elapsed? if yes then
fill up first half of ring buffer - have 8 elapsed? then fill up second
half

4. However the data in the DMA buffer never seems to change - ie I just
play the same 8 periods worth of sound, and the buffer never fills up
with new material from the user space/application/alsa middle layer -
and the calling app blocks ad infinitum, because clearly it is never
told to send any more data


How do I fix this?



-------------------------------------------------------
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: kernel threads etc

[Lee Revell]

On Tue, 2006-03-07 at 21:19 +0000, Adrian McMenamin wrote:
> 0. Create a DMA buffer in SH4 space - this is used as the source for
> the
> dma transfer (the target is in the ARM7's memory space). Alsa seems to
> fill up this buffer easily enough
> 
> 1. Fill the ring buffer completely with first DMA transfer (ring
> buffer
> has space for 8 periods) on receiving the SNDDRV_PCM_TRIGGER_START,
> then
> start the ARM7 playback
> 
> 2. ARM7 fires interrupt on SH4 bus every time period is played
> 
> 3. SH4 interrupt handler counts interrupts - have 4 elapsed? if yes
> then
> fill up first half of ring buffer - have 8 elapsed? then fill up
> second
> half
> 
> 4. However the data in the DMA buffer never seems to change - ie I
> just
> play the same 8 periods worth of sound, and the buffer never fills up
> with new material from the user space/application/alsa middle layer -
> and the calling app blocks ad infinitum, because clearly it is never
> told to send any more data
> 

You should be transferring one period of data every interrupt - why are
you transferring 4 at a time?

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: kernel threads etc

[Adrian McMenamin]

On Tue, 2006-03-07 at 16:29 -0500, Lee Revell wrote:
> On Tue, 2006-03-07 at 21:19 +0000, Adrian McMenamin wrote:
> > 0. Create a DMA buffer in SH4 space - this is used as the source for
> > the
> > dma transfer (the target is in the ARM7's memory space). Alsa seems to
> > fill up this buffer easily enough
> > 
> > 1. Fill the ring buffer completely with first DMA transfer (ring
> > buffer
> > has space for 8 periods) on receiving the SNDDRV_PCM_TRIGGER_START,
> > then
> > start the ARM7 playback
> > 
> > 2. ARM7 fires interrupt on SH4 bus every time period is played
> > 
> > 3. SH4 interrupt handler counts interrupts - have 4 elapsed? if yes
> > then
> > fill up first half of ring buffer - have 8 elapsed? then fill up
> > second
> > half
> > 
> > 4. However the data in the DMA buffer never seems to change - ie I
> > just
> > play the same 8 periods worth of sound, and the buffer never fills up
> > with new material from the user space/application/alsa middle layer -
> > and the calling app blocks ad infinitum, because clearly it is never
> > told to send any more data
> > 
> 
> You should be transferring one period of data every interrupt - why are
> you transferring 4 at a time?
> 
Because you or someone else in an earlier conversation suggested most
people partitioned their buffer in this way. makes no odds :)



-------------------------------------------------------
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: kernel threads etc

[Lee Revell]

On Tue, 2006-03-07 at 21:32 +0000, Adrian McMenamin wrote:
> Because you or someone else in an earlier conversation suggested most
> people partitioned their buffer in this way. makes no odds :)
> 

That's just because it's simpler to explain how ALSA drivers work if you
assume two periods per buffer, and because most hardware supports it and
it gives the lowest latency.  But if your hardware doesn't support two
periods per buffer then you can't do it.

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: kernel threads etc

[Adrian McMenamin]

On Tue, 2006-03-07 at 16:36 -0500, Lee Revell wrote:
> On Tue, 2006-03-07 at 21:32 +0000, Adrian McMenamin wrote:
> > Because you or someone else in an earlier conversation suggested most
> > people partitioned their buffer in this way. makes no odds :)
> > 
> 
> That's just because it's simpler to explain how ALSA drivers work if you
> assume two periods per buffer, and because most hardware supports it and
> it gives the lowest latency.  But if your hardware doesn't support two
> periods per buffer then you can't do it.
> 

I've done this and now I have a familiar problem - I can play out quite
long samples, but they loop around for ever - for some reason 'close' is
not being called on the /dev/dsp device file



-------------------------------------------------------
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: kernel threads etc

[Lee Revell]

On Tue, 2006-03-07 at 00:11 +0000, Adrian McMenamin wrote:
> > When I think of soundcard DMA I mean that you tell the card where in
> > host memory the buffer is, then to start the DMA, and from then on,
> > until you stop it, the device will automatically write audio into
> that
> > area of host memory until you tell it to stop.
> > 
> By buffer you mean the sound card buffer? I don't have that luxury I'm
> afraid. I've got real dma though, just not of that kind.
> 

Modern PCI soundcards don't have any buffers of their own - all they can
do is DMA to/from host memory.

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: kernel threads etc

[Lee Revell]

On Mon, 2006-03-06 at 23:38 +0000, Adrian McMenamin wrote:
> On Mon, 2006-03-06 at 18:11 -0500, Lee Revell wrote:
> > On Mon, 2006-03-06 at 22:27 +0000, Adrian McMenamin wrote:
> > > I have an interrupt handler in my sound driver that calls this:
> > 
> > You never explained why you want to create a kernel thread rather than
> > implementing copy/silence callbacks like the docs say.
> > 
> > Lee
> 
> Reading through the notes it states:
> 
> "The third argument (pos) points the current position offset in frames."
> 
> Presumably that means the position in the playback ring buffer? It's not
> at all clear. 

Yes.  If the buffer contains 1024 frames then pos will range from 0 to
1023.

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

kernel threads etc

[Adrian McMenamin]

I have an interrupt handler in my sound driver that calls this:

dreamcastcard->sleep_aicahw = 1;
wake_up_interruptible(&aicahw);


which is meant to wake up this code in a workqueue:

do{
	wait_event_interruptible(aicahw, (dreamcastcard->sleep_aicahw > 0));
	if (dreamcastcard->sleep_aicahw == 2) return; /* end of the road
signalled */
	snd_printk("The AICA is awake\n");
	/* write to the lower or upper area of the ring buffer? */
	buffer_size= frames_to_bytes(runtime, runtime->buffer_size);
	if (buffer_size > 16384) transfer_size = 16384;
	else transfer_size = buffer_size;
	err = dma_xfer(0, runtime->dma_area, 0x11000 + (dreamcastcard->upper) *
0x4000, transfer_size, 5);
	if (err) goto dma_fail;
	dreamcastcard->upper = 0;
	dreamcastcard->sleep_aicahw = 0;
} while (1);


But while I know the interrupt is being fired and trapped (cheating with
printk), I never see the "The AICA is awake" - is there something wrong
with sleeping inside a kernel thread in this way or some other foible I
should be aware of?




-------------------------------------------------------
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