Reasonable sound hardware parameters?

Reasonable sound hardware parameters?

[Lorenz Kolb]

> Message: 4
> Date: Mon, 28 May 2007 10:52:18 +0200 (CEST)
> From: Jaroslav Kysela <perex@suse.cz>
> Subject: Re: [alsa-devel] Reasonable sound hardware parameters?
> To: Joachim F?rster <mls.JOFT@gmx.de>
> Cc: alsa-devel@alsa-project.org
> Message-ID: <Pine.LNX.4.61.0705281045310.7894@tm8103.perex-int.cz>
> Content-Type: text/plain; charset="iso8859-2"
> 
> On Sat, 26 May 2007, Joachim F?rster wrote:
> 
> >
> > First question: To implement mmap on such kind of device IO memory, 
> > I have to use snd_pcm_lib_mmap_iomem() as mmap() callback - like it 
> > is used in the rme32 driver, right?
> 
> Yes. rme32 is quite similar.
> 
> > Second question: Do the following parameters make sense regarding 
> > the size of the HW ring buffer and period sizes:
> >
> > .buffer_bytes_max=16*1024;
> > .period_bytes_max=8*1024;
> > .period_bytes_min=?? resonable value ??
> 
> 32 or 64
> 
> > .periods_min=2;
> > .periods_max=?? resonable value ??
> 
> 16
> 
> > Furthermore, the sound controller will fire an interrupt after one 
> > period is played. Are there any arguments against these values? Any 
> > comments?
> 
> Yes, I think that the access through a PCI I/O window to a PCI device 
> is much slower than PCI DMA transfers with bursts. I would really 
> consider to design hardware with real DMA. Of course, if it's only 
> experimental stuff, then don't worry.
> 
> 						Jaroslav
> 
> -----
> Jaroslav Kysela <perex@suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, SUSE Labs

Hi Jaroslav,

First of all: thanks for Your answer.
Second: We do not have a PCI Bus. It is an embedded system with an OCP-Bus
(aka OPB).

The ML403 holds a SoC with PPC and FPGA.

So the only difference between DMA with bursts and a dedicated memory (as
far as we do see it) is the amount of time the bus gets occupied.
With dedicated memory the system will (hopefully ;-)) do a burst write each
period. So what happens in DMA case (except the more complex hardware as the
DMA controller has to be written (in VHDL) as well and even more memory is
located at an more complex bus (PLB - processor local bus): the bus will be
occupied twice: (1) CPU writes data to memory. --> start DMA --> (2)
Controller fetches data from memory.
While (2) is in progress the poor CPU is "disconnected" from the bus.
In an embedded system with a not too powerful CPU (PPC 405 @300MHz) this
might be quite inefficient.
Or did we miss something?

Regards,

Lorenz
--
Lorenz Kolb <alsa-dev@lkmail.de>
Embedded specialist
ESIC-Solutions

Re: Reasonable sound hardware parameters?

[Jaroslav Kysela]

On Mon, 28 May 2007, Lorenz Kolb wrote:

> > On Sat, 26 May 2007, Joachim F?rster wrote:
> > 
> > >
> > > First question: To implement mmap on such kind of device IO memory, 
> > > I have to use snd_pcm_lib_mmap_iomem() as mmap() callback - like it 
> > > is used in the rme32 driver, right?
> > 
> > Yes. rme32 is quite similar.
> > 
> > > Second question: Do the following parameters make sense regarding 
> > > the size of the HW ring buffer and period sizes:
> > >
> > > .buffer_bytes_max=16*1024;
> > > .period_bytes_max=8*1024;
> > > .period_bytes_min=?? resonable value ??
> > 
> > 32 or 64
> > 
> > > .periods_min=2;
> > > .periods_max=?? resonable value ??
> > 
> > 16
> > 
> > > Furthermore, the sound controller will fire an interrupt after one 
> > > period is played. Are there any arguments against these values? Any 
> > > comments?
> > 
> > Yes, I think that the access through a PCI I/O window to a PCI device 
> > is much slower than PCI DMA transfers with bursts. I would really 
> > consider to design hardware with real DMA. Of course, if it's only 
> > experimental stuff, then don't worry.

> Hi Jaroslav,
> 
> First of all: thanks for Your answer.
> Second: We do not have a PCI Bus. It is an embedded system with an OCP-Bus
> (aka OPB).
> 
> The ML403 holds a SoC with PPC and FPGA.
> 
> So the only difference between DMA with bursts and a dedicated memory (as
> far as we do see it) is the amount of time the bus gets occupied.
> With dedicated memory the system will (hopefully ;-)) do a burst write each
> period. So what happens in DMA case (except the more complex hardware as the
> DMA controller has to be written (in VHDL) as well and even more memory is
> located at an more complex bus (PLB - processor local bus): the bus will be
> occupied twice: (1) CPU writes data to memory. --> start DMA --> (2)
> Controller fetches data from memory.
> While (2) is in progress the poor CPU is "disconnected" from the bus.
> In an embedded system with a not too powerful CPU (PPC 405 @300MHz) this
> might be quite inefficient.
> Or did we miss something?

Probably not :-) I was speaking about standard PCI architecture in PC. 
Your design is quite different. Anyway, I wonder for what purpose you 
need such embedded platform with Linux? Perhaps, I'm too curious ;-)

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

Re: Reasonable sound hardware parameters?

[Lorenz Kolb]

On Mon, 28 May 2007 Jaroslav, Kysela wrote:
 
> On Mon, 28 May 2007, Lorenz Kolb wrote:
> > Or did we miss something?
> 
> Probably not :-) I was speaking about standard PCI architecture in PC.
> Your design is quite different. Anyway, I wonder for what purpose you
> need such embedded platform with Linux? Perhaps, I'm too curious ;-)

You know what happened to the cat because of curiosity? ;-)
I know it is not polite to answer with a question, but why not using Linux
in embedded platforms?
Linux allows full control over the kernel (ok, as long as one complies to
the GPL), it is widely spread and offers an enormous amount of client
software and even more it is free (of charge, not of cost).
And just have a look at companies like AVM. They do have great success using
Linux in the embedded field.
Unfortunately a multi-media-box (that's at least the goal) will not be multi
without audio ;-)

> 
> 						Jaroslav
> 
> -----
> Jaroslav Kysela <perex@suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, SUSE Labs

Lorenz

--
Lorenz Kolb <alsa-dev@lkmail.de>
Embedded specialist
ESIC-Solutions

Re: Reasonable sound hardware parameters?

[Jaroslav Kysela]

On Tue, 29 May 2007, Lorenz Kolb wrote:

> On Mon, 28 May 2007 Jaroslav, Kysela wrote:
>  
> > On Mon, 28 May 2007, Lorenz Kolb wrote:
> > > Or did we miss something?
> > 
> > Probably not :-) I was speaking about standard PCI architecture in PC.
> > Your design is quite different. Anyway, I wonder for what purpose you
> > need such embedded platform with Linux? Perhaps, I'm too curious ;-)
> 
> You know what happened to the cat because of curiosity? ;-) I know it is 
> not polite to answer with a question, but why not using Linux in 
> embedded platforms? Linux allows full control over the kernel (ok, as 
> long as one complies to the GPL), it is widely spread and offers an 
> enormous amount of client software and even more it is free (of charge, 
> not of cost). And just have a look at companies like AVM. They do have 
> great success using Linux in the embedded field. Unfortunately a 
> multi-media-box (that's at least the goal) will not be multi without 
> audio ;-)

Yes, I know about Linux flexibility, but I'm curious what's special in 
your hardware platform - or what was the reason to design a new platform 
(you mentioned that main CPU is not very powerful). Several PC based 
platforms exist with Geode or VIA processors which has enough I/Os 
integrated including AC97 sound and PCI slots for further expansion..
Maybe size of final product or a special acceleration?

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

Re: Reasonable sound hardware parameters?

[Lorenz Kolb]

On Tue, 29 May 2007 Jaroslav wrote:
> 
> Yes, I know about Linux flexibility, but I'm curious what's special in
> your hardware platform - or what was the reason to design a new
> platform
> (you mentioned that main CPU is not very powerful). Several PC based
> platforms exist with Geode or VIA processors which has enough I/Os
> integrated including AC97 sound and PCI slots for further expansion..
> Maybe size of final product or a special acceleration?
> 
> 						Jaroslav

Ok, now I got Your point. The project is all about being highly energy
efficient, flexible and provide massive parallelism (and we are not talking
about just 4 cores like in an Intel). Unfortunately size matters as well and
you'll guess it: it has to be cost efficient. Probably You know the word
"eierlegende Wollmilchsau" (dict.leo.org translates it with: "all-in-one
device suitable for every purpose" though the humor gets lost with that
translation), actually that's the goal.

Regards,

Lorenz

Reasonable sound hardware parameters?

[Joachim Förster]

Hi ALSA devs,

as I already described in one of my last posts on the list, I'm going to
write a ALSA driver for a sound controller which will also be "written"
at the same time (VHDL for FPGA) - on top of an embedded system (Xilinx
ML403 EvalBoard, PowerPC 405). We will do playback feature only.

The point is, that we will have _no_ real DMA and we don't want to use
the copy/silence or ack/workqueue (with intermediate buffer). So we
decided to move the ring buffer, which usually exists in RAM into the
sound controller and handle it as some kind of device IO memory, which
should be mmap'able (kernel function io_remap_pfn_range()). So, the
important goal is, to have mmap feature in the ALSA driver.

First question: To implement mmap on such kind of device IO memory, I
have to use snd_pcm_lib_mmap_iomem() as mmap() callback - like it is
used in the rme32 driver, right?

Second question: Do the following parameters make sense regarding the
size of the HW ring buffer and period sizes:

.buffer_bytes_max=16*1024;
.period_bytes_max=8*1024;
.period_bytes_min=?? resonable value ??
.periods_min=2;
.periods_max=?? resonable value ??

Furthermore, the sound controller will fire an interrupt after one
period is played.
Are there any arguments against these values? Any comments?

Thanks,
 Joachim

Re: Reasonable sound hardware parameters?

[Jaroslav Kysela]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1837 bytes --]

On Sat, 26 May 2007, Joachim Förster wrote:

> Hi ALSA devs,
> 
> as I already described in one of my last posts on the list, I'm going to
> write a ALSA driver for a sound controller which will also be "written"
> at the same time (VHDL for FPGA) - on top of an embedded system (Xilinx
> ML403 EvalBoard, PowerPC 405). We will do playback feature only.
> 
> The point is, that we will have _no_ real DMA and we don't want to use
> the copy/silence or ack/workqueue (with intermediate buffer). So we
> decided to move the ring buffer, which usually exists in RAM into the
> sound controller and handle it as some kind of device IO memory, which
> should be mmap'able (kernel function io_remap_pfn_range()). So, the
> important goal is, to have mmap feature in the ALSA driver.
> 
> First question: To implement mmap on such kind of device IO memory, I
> have to use snd_pcm_lib_mmap_iomem() as mmap() callback - like it is
> used in the rme32 driver, right?

Yes. rme32 is quite similar.

> Second question: Do the following parameters make sense regarding the
> size of the HW ring buffer and period sizes:
> 
> .buffer_bytes_max=16*1024;
> .period_bytes_max=8*1024;
> .period_bytes_min=?? resonable value ??

32 or 64

> .periods_min=2;
> .periods_max=?? resonable value ??

16

> Furthermore, the sound controller will fire an interrupt after one 
> period is played. Are there any arguments against these values? Any 
> comments?

Yes, I think that the access through a PCI I/O window to a PCI device is 
much slower than PCI DMA transfers with bursts. I would really consider to 
design hardware with real DMA. Of course, if it's only experimental stuff, 
then don't worry.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel