On Jun 14, 2021, at 05:15, Alejandro olivan Alvarez
<[email protected]> wrote:
> I think I understand what you're refering to .... The thing is that, through
> HPI, the number of Inputs/outputs do match 'only' the number of physical
> Inputs/outputs of the card, which, may or not (In my experience usually not)
> match the number of of actual PCM inputs / outputs supported by the card.
>
It depends on the model. There were some early oddball ones that had things
like multiple physical outputs each with a single, dedicated output stream that
couldn’t be routed to anything else, but I’m pretty sure that ASI has
end-of-lifed (killed?) all of those models by now. Since the introduction of
the ‘anything to anywhere’ architecture (yes, that is their actual marketing
phrase), things are pretty consistently as you describe.
> For instance, here I'm testing with an ASI5810 and an ASI5720, which both
> feature 4 PCM playbacks and 2 PCM records (although both having different
> number of physical in/out numbers and types), so, from an ALSA point of view,
> both feature 4 playback/outs and 2 record/ins, which can be used, and then
> routed, using the ALSA mixer tomanage the card internal router, to/from any
> of the card's analog/digital physical in/outs (Mostly the way Windows users
> know to use ASI cards through the ASI manager GUI)
>
> By contrast, from HPI/Rivendell's point of view, apparently only 'physical
> endpoints' seems to matter... So, ASI5810 has 'only' 2 inputs / 1 output ,
> and the ASI5720 fatures 'only' 2 inputs / 2 outputs.
>
Correct, and that’s an extremely intentional design decision. End users for the
most part don’t care about which particular output stream gets used; what they
do care about is *where* the audio is going to appear when it comes out of the
card (the ‘where’ being either a physical connector or a virtual location for
AoIP cards like the 6685 or 6316). The output stream assignment and mixer level
management is handled completely automatically by Rivendell; end users *never*
have to futz with it or even be aware that it’s there.
Hence, my concern about about mixer state coherency. Back when the ALSA Project
started including the ASI driver with their standard driver package, we
discovered that users were frequently shooting themselves in the foot by
enabling the *ALSA* driver in addition to the HPI one; the result being general
mayhem and train wreck. Hence, the standard Rivendell installer now blacklists
the ASI ALSA driver.
> I agree but, that, given Rivendell's perfect integration with Jack, providing
> plenty of in/out, the best approach is to completely forget about ALSA
> PCM<->physical routing stuff and stick to rivendell's native HPI support.
>
For Rivendell, yes, absolutely. And any other application is going to need some
understanding of the unique ASI mixer architecture in order to work properly
with those cards. That being the case, you might as well go whole hog and use
HPI, as that will also give you full access to all of the advanced features
(TSX, MPEG) that ALSA’s APIs don’t know how to deal with. At the end of the
day, it turns out that ALSA support for ASI cards is just not terribly useful.
Cheers!
|---------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|---------------------------------------------------------------------|
| A room without books is like a body without a soul. |
| |
| -- Cicero |
|---------------------------------------------------------------------|
_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
