Re: starting audio applications via a common wrapper?
Hi,
> EM> That is precisely the point I want to address. Using the argv[0] trick
> EM> (diverting, let's say, hydrogen to hydrogen.real and
> EM> symlinking /usr/bin/hydrogen to this wrapper application) we would have
> EM> the advantage of being able to decide what CLI arguments to pass to the
> EM> real application so it connects to the detected running setup, and we
> EM> would not have to change anything in the menu system, which would keep
> EM> the user experience consistent.
>
> I think it's a good idea, at least till a consensus is reached in the
> Linux Audio community about how to manage the situation.
>
> If did something quite similar with the ALSA Modular Synth package (ams):
>
> http://svn.debian.org/wsvn/demudi/ams/trunk/debian/patches/11ams_launch_script.dpatch?op=file&rev=0&sc=0
Hmm... this has the following defects.
1. LADSPA_PATH does not contain /usr/local/ladspa
2. only checks if there is jackd process, which might be owned by other user.
3. invokes ams.real as a child process, not 'exec', which means the sequence
ams & PID=$!
will not obtain the process ID of ams.
IMO, some C code that really tests existence of jackd would be required.
Or some really simple check like the following will work for jackd:
When not running:
$ jack_lsp ; echo $?
JACK server not running
1
When running:
$ jack_lsp ; echo $?
alsa_pcm:capture_1
alsa_pcm:capture_2
alsa_pcm:playback_1
alsa_pcm:playback_2
alsa_pcm:playback_3
alsa_pcm:playback_4
alsa_pcm:playback_5
alsa_pcm:playback_6
0
For a generic Debian solution, there is a need for user-based prioritization.
/etc/debian-multimedia/audio-priorities:
jack
alsa
oss
~/.audio-priorities: user preferences
Apps will probably call the command:
debian-multimedia-audio 'list of supported audio transports'
and the command shall return something like
'jack'
That said, I'm not too sure if I want every app to be invoked from a shell wrapper.
regards,
junichi
--
dancer@{debian.org,netfort.gr.jp} Debian Project
Reply to: