vanDongen/Gilcher hat gesagt: // vanDongen/Gilcher wrote:
The biggest problem currently with ALSA is the .asoundrc file. With a hammerfall it is usually neccesary to set up one, unless you want to use non-interleaved 24 channel audio. This thing is _really_ poorly documented, but if you search on alsa-dev you can find examples that help a bit.
With my Midiman card I can in most cases (and in other software, not PD, where this is not an option yet) just use the "default" plugin PCM, that is preconfiguerd by ALSA.
I think that most problems come from not setting up the correct audio device for the application using ALSA's conversion library, but instead trying to access the hw directly with some format that the hardware doesn't support.
Another quick fix is to use plughw:0,0 as your devicename in stead of hw:0,0
This isn't possible, at least with pd-0.35+test3, because of the hardcoding if "hw:x,x" in s_main.c. And this might be the reason, why PD gives problems with a Hammerfall and ALSA. It maybe has a too naive alsa-device selection option. Currently this is:
-alsadev <n> -- ALSA device # (counting from 1) or name: default hw:0,0
The "hw" PCMs in ALSA can be tricky. The plugin layer in ALSA is better suited for normal usage. Maybe it would be better, if the alsadev option allowed the user to specify the PCM on his own. A lot of ALSA native software (aplay/arecord, ecasound, Ardour,...) does it this way, to give the user flexibility through the plugin or the hardware layer.
Just specifying a device number might be to limited for some use cases.
Ciao,
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\