[PD] 64 channel audio output with RME HDSP-Madi

[zmoelnig at iem.at]

Quoting "J. Schmidt" <schmidje at idmt.fraunhofer.de>:

> Hi,
>
> i have a problem with audio output on Linux with the RME Madi-card.
> I use Alsa and it seems ok, but i get only one input and output channel.
> My pdsettings are set up for 64 input and output channels.
>
> PD says
>
> - requested channels=0 but used=1
> - playback device with 1 channels and buffer_time 42666 us opened
> - requested channels=0 but used=1
>
> when i turn the audio on.
>
> Any hint? Or has anybody ever got pd to run as many channels?


yes, we (the iem) are using the MADI card with 64 channels.

the problem is, that pd (0.39.2) seems to just ignores the channel# 
when doing alsa (or is it some special thing like alsamm, dunno) and 
defaults it to 0.
when it comes to opening the device, pd queries the device about the 
max. and min. number of channels the device supports. now the madi has 
a minimum of 1 channels and a maximum of 64 channels.
the requested number of channels (in our case 0! because the number of 
channels you typed in ist just ignored!!) is clamped between these 2 
values, which results in 1.
that is why you only get 1 channel.

i think this doesn't happen on other devices, because most of them just 
support one fixed number of channels (min.chan==max.chan)

now what to do against it?
i have once patched the s_audio_alsa.c, so that if the requested 
channel is 0, this value is not clamped between the min. and max. 
#channels but rather set to the max. #channels.
i will see if i can find it.
wini (who - as you probably know - has written both the madi-drivers 
and the original memory-mapped alsa support for pd) has done something 
different to make it work, but i don't know what exactly.

of course, the cleanest solution would be to not-ignore the number of 
channels requested by the user.

mfg.a.r
IOhannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 1718 bytes
Desc: ?ffentlicher PGP-Schl?ssel
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20060324/571ba1a0/attachment.key>