On Thu, 2011-02-03 at 09:31 -0600, pl bossart wrote:
Also, more work is required to separate ALSA card from UCM card (to support virtual or mixed "soundcards").
Agreed, but Margarita will initially be targeting a simpler system with one sound card and then move on to support a virtual sound card.
I quickly looked at the code. Interesting. I was thinking of a different approach where a separate pulseaudio module would open the use case manager, get the list of cards and verbs. this would be done on startup. Doing this inside module-alsa-card results in redundant activity, you're going to re-open and read the verbs for each card.
I should say that the initial design and patch implementation was carried out before Jaroslav added the virtual card support. The initial plan was to compute UCM values per card at startup.
This code is also experimental, Margarita planned to see what worked best with one card at first before moving to virtual card support.
I am also concerned about the card_set_profile() code in module-alsa-card if (nd->profile->is_ucm) { pa_log_debug("set UCM %s", nd->profile->name + 4); return snd_use_case_set(nd->profile->uc_mgr, verb, nd->profile->name + 4); } There's an awful amount of code after the return to handle multiple sinks that may become active for a given profile. Even if you have a single card, it's not clear to me how multiple devices would be handled (eg. voice, music, tones in the 4430 case) if you bypass this code. Are they considered as different sinks from a PulseAudio perspective? The routing and how devices allowed in a specific use case are exposed in PulseAudio isn't clear to me at all.
I don't think Margarita has got this far yet.
Last, looking at the code, I saw this comment /* FIXME: UCM needs to provide API to acquire verb comments */ A change is not needed, the list of verbs already comes as verb0, comment0, verb1, comment1, etc.
Again, this comment was from the ancient code.
My $0.02 -Pierre
I've CC'ed Colin for his $0.02 too. I do agree though, that with virtual card support it does seem right to create a new Pulseaudio module to manage UCM.
At a high level, the new module could :-
Compute use cases for each sound device at init { if (ucm config exists) use UCM config else use existing config method }
Whilst Pulseaudio would use computed use case values for every new client stream (using module-intended-roles ?).
Thoughts ?
Liam