Re: [Jack-Devel] speaker management

"Patrick Shirkey" <[hidden]> writes:
> On Wed, December 12, 2012 10:46 am, Arnold Krille wrote:
>> The average jack session is with several apps all used for one project.
>> you save the project and want to save the settings for all the apps.
>> you restore (aka load) a project and want all the apps to come up again
>> with the correct settings. All current session managers aim to make
>> this as simple as possible (preferable by even supporting apps that
>> don't have native session-management support). And thats a fine goal.
>>
>> But when you do drc and/or ambisonics you end with a setup slightly
>> more complicated: there are some apps that are independant of the
>> project and stationary to the machine. Some of these apps might even be
>> the ones all the other apps should use as "hardware outputs" instead of
>> the real hardware outputs.
>> No problem when a) the session manager ignores these apps and b) the
>> project is not meant to be movable to a different machine.
>> By making session-management easier for 'most' people, todays
>> session-managers
>> break a) and forcefully support apps that don't want to be supported.
>> And as neither jack supports something like static port aliases nor
>> as session-managers correctly support the notion of distinct apps
>> as "the global environment", b) breaks. Because nowadays the session
>> connects to "alsa_pcm:playback_[12]" on one machine and has to connect
>> to "jconvolver:in_[12]" on another machine.

How this is not solved in ladish? This is exactly the reason for its
studio/room separation.

>> So while session management nowadays is easy for 'most' people and
>> use-cases, its actually made impossible for these special cases.
>> Special cases like: I have this super-cool ardour-project using two
>> dozen synths and playing out to my native home-cinema surround-set. And
>> the audio is so cool that I want to play the same project on one of the
>> bigger ambisonics/wfs setups at the next LAC. Only my project connects
>> to 'alsa_pcm:playback_[1-6]' and when I do that on the wfs-machine I am
>> lucky when nothing of the hardware breaks because I sent my bass-beats
>> to the highest speaker of a four-way...

This is solved years ago in ladish.

>>> If the app doesn't have support for jack session management how can
>>> the session manager be in the way?
>>
>> See above, when you write a session-manager for audio and want it to be
>> used, you support apps that don't support you...

Yes, ladish can reconnect apps that don't know about session
support. Some other session management system can do it as well.

>> There are probably some easy solutions to these problems outlined
>> above. But its "special cases" and it seemed to me the last years that
>> many developers don't want to deal with this and don't want to listen
>> to the people that have to deal with this.

I dealed with this kind of special cases for years. Did I miss some of
them?

> This all looks solveable to me. We have a few specific limitations. What
> is the easiest way to enable the flexibility required?

install jackdbus and ladish :P

>> But I am happy if I am proven wrong: if there is a session-management
>> for audio-projects that knows which app is part of the project and
>> which is part of the environment. If there is even a session-management
>> that knows about something like "the environment" apart from
>> alsa_pcm.

ladish

> We can assign static names to jack ports. IIUC, the main issue appears to
> be that alsa i/o cannot be easily renamed/mapped in a session file.

jack aliases can do this for you but from my POV they are just a
workaround for the real problem. Obviously I think the way ladish solves
this issue is better :)

> So do we need a way to override the jack portnames in the JACK API?
>
> Seems like a reasonable addition to the API to me.

we already have it - jack aliases (altrough i dont recommend using them)

> Can you isolate the other issues that you feel would not be solved in this
> case?

I'm interested in this as well.

-- 
Nedko Arnaudov <GnuPG KeyID: 5D1B58ED>

1355304872.28767_0.ltw:2, <87r4mvbon9.fsf at arnaudov dot name>