some questions regarding multichannel devices

some questions regarding multichannel devices

[Daniel Mack]

Hi all,

I'm somehow confused about is the relationship between

	- the number of registered snd_pcm_t instances
	- the number of substreams (4th and 5th param to snd_pcm_new()) and
	- the value of channels_min, channels_max in my snd_pcm_hardware_t
	  struct

If the device has multiple stereo input and outputs, where and how do I
note that? Is it up to the caller how many streams are actually read/ 
written?
The hardware is not capable of only using some of the hardware channels,
so I would have to throw away data after reception and fake data when  
sending
the stream, repectively.

Also, does a driver need to take care about supporting as much data  
formats
as possible (16/24/32 bits, LE/BE, ...)? Or is there any layer taking  
care
about proper conversion? And if there is such a layer, does any tool  
make
use of that? At least, aplay refused to play a big-endian wave file thru
a device which only supports little-endian data transport according  
to the
snd_pcm_hardware_t struct.

I couldn't find any comprehensive information about that.

Thanks for any hint.
Again, please Cc: me personally in replies, I'm still not subscribed.

Greets,
Daniel



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: some questions regarding multichannel devices

[Lee Revell]

On Sun, 2006-01-22 at 23:39 +0100, Daniel Mack wrote:
> Hi all,
> 
> I'm somehow confused about is the relationship between
> 
> 	- the number of registered snd_pcm_t instances
> 	- the number of substreams (4th and 5th param to snd_pcm_new()) and
> 	- the value of channels_min, channels_max in my snd_pcm_hardware_t
> 	  struct
> 

These should be set to reflect the capabilities of the hardware.
alsa-lib takes care of translating various formats and channel counts to
something the hardware can understand.  You don't have to worry about it
in the driver.

Substreams are only relevant if your device supports hardware mixing.

> If the device has multiple stereo input and outputs, where and how do I
> note that? Is it up to the caller how many streams are actually read/ 
> written?
> The hardware is not capable of only using some of the hardware channels,
> so I would have to throw away data after reception and fake data when  
> sending
> the stream, repectively.
> 
> Also, does a driver need to take care about supporting as much data  
> formats
> as possible (16/24/32 bits, LE/BE, ...)? Or is there any layer taking  
> care
> about proper conversion? And if there is such a layer, does any tool  
> make
> use of that? At least, aplay refused to play a big-endian wave file thru
> a device which only supports little-endian data transport according  
> to the
> snd_pcm_hardware_t struct.
> 
> I couldn't find any comprehensive information about that.
> 

See above - alsa-lib handles all these details for you, all you need to
consider when writing the driver is what the hardware supports.

> Thanks for any hint.
> Again, please Cc: me personally in replies, I'm still not subscribed.
> 
> Greets,
> Daniel
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: some questions regarding multichannel devices

[Daniel Mack]

Hi Lee,

Thanks for your reply.

On Jan 22, 2006, at 11:46 PM, Lee Revell wrote:
>> 	- the number of registered snd_pcm_t instances
>> 	- the number of substreams (4th and 5th param to snd_pcm_new()) and
>> 	- the value of channels_min, channels_max in my snd_pcm_hardware_t
>> 	  struct
>
> These should be set to reflect the capabilities of the hardware.
> alsa-lib takes care of translating various formats and channel  
> counts to
> something the hardware can understand.  You don't have to worry  
> about it
> in the driver.
>
> Substreams are only relevant if your device supports hardware mixing.

So let's say I have a device with 2 stereo inputs and 2 stereo outputs.
For this device, I would

	- register ONE instance of snd_pcm_t
	- register ONE input substream and ONE output substream
	- set channels_min = channels_max = 4 for both the input
	  and the output struct.

Is that right?

>> Also, does a driver need to take care about supporting as much data
>> formats
>> as possible (16/24/32 bits, LE/BE, ...)? Or is there any layer taking
>> care
>> about proper conversion? And if there is such a layer, does any tool
>> make use of that? At least, aplay refused to play a big-endian  
>> wave file thru
>> a device which only supports little-endian data transport according
>> to the
>> snd_pcm_hardware_t struct.
>
> See above - alsa-lib handles all these details for you, all you  
> need to
> consider when writing the driver is what the hardware supports.

Which tool would recommend for testing, though? As I said, aplay
definitely failed to do any conversion but simply refused to play
a file which was not coded in a way the hardware could understand
natively.

Also, I could not find a verbose tool for inspecting available ALSA
components found on a system, dumping all information which is available
theoretically. Is there such a thing?

Greets,
Daniel



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: some questions regarding multichannel devices

[Lee Revell]

On Mon, 2006-01-23 at 00:33 +0100, Daniel Mack wrote:
> Hi Lee,
> 
> Thanks for your reply.
> 
> On Jan 22, 2006, at 11:46 PM, Lee Revell wrote:
> >> 	- the number of registered snd_pcm_t instances
> >> 	- the number of substreams (4th and 5th param to snd_pcm_new()) and
> >> 	- the value of channels_min, channels_max in my snd_pcm_hardware_t
> >> 	  struct
> >
> > These should be set to reflect the capabilities of the hardware.
> > alsa-lib takes care of translating various formats and channel  
> > counts to
> > something the hardware can understand.  You don't have to worry  
> > about it
> > in the driver.
> >
> > Substreams are only relevant if your device supports hardware mixing.
> 
> So let's say I have a device with 2 stereo inputs and 2 stereo outputs.
> For this device, I would
> 
> 	- register ONE instance of snd_pcm_t
> 	- register ONE input substream and ONE output substream
> 	- set channels_min = channels_max = 4 for both the input
> 	  and the output struct.
> 
> Is that right?
> 

Yes, if the hardware supports addressing all 4 channels at once (eg a
single interrupt enable register and DMA setup).  If the hardware is
designed to see this as 2 independent stereo devices, then you would
create one card with two stereo subdevices.

Look at some existing drivers for details or the "Writing an ALSA
driver" document.

> >> Also, does a driver need to take care about supporting as much data
> >> formats
> >> as possible (16/24/32 bits, LE/BE, ...)? Or is there any layer taking
> >> care
> >> about proper conversion? And if there is such a layer, does any tool
> >> make use of that? At least, aplay refused to play a big-endian  
> >> wave file thru
> >> a device which only supports little-endian data transport according
> >> to the
> >> snd_pcm_hardware_t struct.
> >
> > See above - alsa-lib handles all these details for you, all you  
> > need to
> > consider when writing the driver is what the hardware supports.
> 
> Which tool would recommend for testing, though? As I said, aplay
> definitely failed to do any conversion but simply refused to play
> a file which was not coded in a way the hardware could understand
> natively.
> 

You have to use "aplay -d plughw:0", not "aplay -d hw:0".  Eventually
you would create a configuration for your card in /usr/share/alsa/cards/
that defines a "default" PCM using dmix and plughw.

> Also, I could not find a verbose tool for inspecting available ALSA
> components found on a system, dumping all information which is available
> theoretically. Is there such a thing?
> 

Look at the alsa-lib docs, there are various "dump" functions, or try
"aplay -v".  Also look at the files under /proc/asound.

> Greets,
> Daniel
> 
> 



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: some questions regarding multichannel devices

[Daniel Mack]

Hi Lee,

On Jan 23, 2006, at 1:09 AM, Lee Revell wrote:
> Look at some existing drivers for details or the "Writing an ALSA
> driver" document.

I read that. But besides the fact that it seems to be somewhat
outdated ('struct snd_pcm' vs. 'snd_pcm_t' confusion all over
the place), I couldn't find this issue explained. Thanks for
the hint.

> You have to use "aplay -d plughw:0", not "aplay -d hw:0".

I guess you mean '-D', not '-d'? Unfortunately, This also does
not help. I still get:

$ aplay -D plughw:0 test.wav
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz,  
Stereo
aplay: set_params:935: Unable to install hw params:
ACCESS:  RW_INTERLEAVED
FORMAT:  S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 44100
PERIOD_TIME: (46439 46440)
PERIOD_SIZE: 2048
PERIOD_BYTES: 8192
PERIODS: 4
BUFFER_TIME: (185759 185760)
BUFFER_SIZE: 8192
BUFFER_BYTES: 32768
TICK_TIME: 4000

and I suspect the S16_LE to be the reason. My snd_pcm_hardware_t looks
like this:

{
         .info           = (SNDRV_PCM_INFO_MMAP |  
SNDRV_PCM_INFO_DOUBLE | SNDRV_PCM_INFO_INTERLEAVED |
                            SNDRV_PCM_INFO_BLOCK_TRANSFER),
         .formats        = SNDRV_PCM_FMTBIT_S24_BE |  
SNDRV_PCM_FMTBIT_S16_BE,
         .rates          = (SNDRV_PCM_RATE_44100 |  
SNDRV_PCM_RATE_48000 |
                            SNDRV_PCM_RATE_96000 |  
SNDRV_PCM_RATE_192000),
         .rate_min       = 44100,
         .rate_max       = 192000,
         .channels_min   = 2,
         .channels_max   = 2,
         .buffer_bytes_max = 32768,
         .period_bytes_min = 4096,
         .period_bytes_max = 32768,
         .periods_min    = 1,
         .periods_max    = 1024,
};

I have *no* ~/.asoundrc and no special entries about my hardware in
/etc/asound* or /usr/share/alsa/*/*.

What do I have to do to get the glue logic working?

Greets,
Daniel




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: some questions regarding multichannel devices

[Lee Revell]

On Mon, 2006-01-23 at 13:35 +0100, Daniel Mack wrote:
> Hi Lee,
> 
> On Jan 23, 2006, at 1:09 AM, Lee Revell wrote:
> > Look at some existing drivers for details or the "Writing an ALSA
> > driver" document.
> 
> I read that. But besides the fact that it seems to be somewhat
> outdated ('struct snd_pcm' vs. 'snd_pcm_t' confusion all over
> the place), I couldn't find this issue explained. Thanks for
> the hint.
> 

You must be looking at an old version of the document or ALSA.  The
typedefs were removed from the ALSA code. 

> > You have to use "aplay -d plughw:0", not "aplay -d hw:0".
> 
> I guess you mean '-D', not '-d'? Unfortunately, This also does
> not help. I still get:
> 
> $ aplay -D plughw:0 test.wav
> Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz,  
> Stereo
> aplay: set_params:935: Unable to install hw params:
> ACCESS:  RW_INTERLEAVED
> FORMAT:  S16_LE
> SUBFORMAT:  STD
> SAMPLE_BITS: 16
> FRAME_BITS: 32
> CHANNELS: 2
> RATE: 44100
> PERIOD_TIME: (46439 46440)
> PERIOD_SIZE: 2048
> PERIOD_BYTES: 8192
> PERIODS: 4
> BUFFER_TIME: (185759 185760)
> BUFFER_SIZE: 8192
> BUFFER_BYTES: 32768
> TICK_TIME: 4000
> 
> and I suspect the S16_LE to be the reason. My snd_pcm_hardware_t looks
> like this:
> 

It should be a struct snd_pcm_hardware, upgrade your ALSA version.

> {
>          .info           = (SNDRV_PCM_INFO_MMAP |  
> SNDRV_PCM_INFO_DOUBLE | SNDRV_PCM_INFO_INTERLEAVED |
>                             SNDRV_PCM_INFO_BLOCK_TRANSFER),
>          .formats        = SNDRV_PCM_FMTBIT_S24_BE |  
> SNDRV_PCM_FMTBIT_S16_BE,
>          .rates          = (SNDRV_PCM_RATE_44100 |  
> SNDRV_PCM_RATE_48000 |
>                             SNDRV_PCM_RATE_96000 |  
> SNDRV_PCM_RATE_192000),
>          .rate_min       = 44100,
>          .rate_max       = 192000,
>          .channels_min   = 2,
>          .channels_max   = 2,
>          .buffer_bytes_max = 32768,
>          .period_bytes_min = 4096,
>          .period_bytes_max = 32768,
>          .periods_min    = 1,
>          .periods_max    = 1024,
> };
> 
> I have *no* ~/.asoundrc and no special entries about my hardware in
> /etc/asound* or /usr/share/alsa/*/*.
> 
> What do I have to do to get the glue logic working?
> 

AFAICT this should work... maybe someone else on the list can help.

Lee



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642