Re: [Protux-devel] snd_pcm_hw_params_set_format returns: invalid format

[Remon Sijrier]

After 3 days searching on the internet and alsa-app. code I saw this thread in 
the AlsaPlayer-devel:

<snip>
Here is the message. It looks as if the problem is that the HW device on
the ice1712 chipset only accepts S32_LE format (which I know is the case)
and alsaplayer is trying to force S16_LE. I'm not sure whether it would be
better to switch to using alsa plugin devices or for alsaplayer to try a
range of formats until it finds one the HW likes. The other HW setting
that I think will nail us is that the HW devices only operate on 10
channels, which is set a few lines later.
<snip>

This is exactly the same problem I have. But what I didn't understand was that 
alsaplayer only uses the S16_LE format which as stated above isn't supported 
by my soundcard, but alsaplayer works just fine here. Searching through the 
archive didn't show more information, but the only way to get it to work is 
using the "plughw:x,y" device instead of "hw:x,y" also stated above (to 
switch to using alsa plugin devices)
I cannot find it back in the source code of alsaplayer, but I tried it with 
protux MADM and guess what: It works.

So it is maybe a good idea to use this "plughw" device instead of "hw" for the 
moment?
So I can test and use protux a bit more as I did for the past days. Also, this 
plughw device uses the alsa libs to convert the given rate and bith depth to 
something the soundcard understands. The following question came up in my 
mind: 'Is it necessary at all to convert a given format into another format 
as it can already be done with alsa?'
It should be nice of course if protux can handle 24 bits audio, but as I see 
in other apps, the playback conversion to fit the card capabilities is always 
done by alsa itself. (I'm not sure about Jack, but as far as I can see it 
also uses the "plughw" device, it detects the propper values for the card, 
but there's no code who gives a feedback about the bit depth the card uses, 
and after this detection it uses the same way of making the card ready as 
MADM does)
Just an idea.

As I mentioned in another mail, I'm not a experienced C++ developer, but if I 
can help (for example with the alsa stuff, I read und studied it for 3 days 
now :( *sigh* ) with coding some things.

Greetings,

Remon