Re: some questions regarding multichannel devices

[Lee Revell <rlrevell@joe-job.com>]

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