Re: [Jack-Devel] speaker management

PrevNext  Index
DateWed, 12 Dec 2012 21:31:31 +1100
From Patrick Shirkey <[hidden] at boosthardware dot com>
To[hidden] at lists dot jackaudio dot org
In-Reply-ToNedko Arnaudov Re: [Jack-Devel] speaker management
Follow-UpNedko Arnaudov Re: [Jack-Devel] speaker management
On Wed, December 12, 2012 8:33 pm, Nedko Arnaudov wrote:
> "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)
>

Are "jack aliases" unique to  LADISH? I haven't heard of them in the JACK
API?

Maybe it would be helpful if you could give a step by step instruction on
how to achieve what Arnold is looking for with ladish and then we can test
it out to see if it does the trick?


>> Can you isolate the other issues that you feel would not be solved in
>> this
>> case?
>
> I'm interested in this as well.
>




--
Patrick Shirkey
Boost Hardware Ltd
PrevNext  Index

1355308301.2223_0.ltw:2, <61239.188.25.62.163.1355308291.squirrel at boosthardware dot com>