[alsa-devel] Reasonable sound hardware parameters?
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
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
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
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
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
participants (2)
-
Jaroslav Kysela -
Lorenz Kolb