hi, Am Donnerstag, 18. Juni 2020, 16:06:23 CEST schrieb Takashi Sakamoto: > The domain specific language in alsa-lib is not so easy to understand > and control. The result affects to all of ALSA applications like pulseaudio. > It's better to use alsa_in/alsa_out for the purpose to avoid unexpected > influences, IMO... i'll probably try both, and maybe FFADO as well. my goal is a solution that reliably works when we (my band) start recording again. it's a pity alsa currently can't transparently take care of this. it looks like basically everything is in place, but you're left with that IKEA feeling, a collection of parts and a construction manual in your hand. when you plug in a 24-channel sound card and alsa successfully detects all of them, as a user you'd expect the single card that is actually offered by alsa to just provide all those channels. that the board internally might use mutliple chips is something you shouldn't have to worry about/figure out. i'd argue there's exactly one configuration that everyone would expect to get from a board like this, and that's all channels in one device. it would do no harm to automatically configure it like this by default. should someone actually prefer to have split devices for whatever use case, IMHO that should be the exception to be configured manually. > > let me know if you need anything else. > > Hm. If you hear sound with periodical noise, please report it. The > dice-based device is known as one of the devices to require drivers for > media clock recovery. In detail, please read the other case[1]. i'll check it out. we have just bought the board second-hand to replace a phonic helixboard that broke after ~10 years in our studio. i'm just starting to get familiar with it and haven't recorded much more than a proof of basic functionality yet. viele grüße :: m.eik
