Re: [Jack-Devel] How do I replicate the -P parameter when using dbus
Hi Nedko
On 22/11/11 17:37, Nedko Arnaudov wrote:
> Hi Roger,
>
> Roger James<[hidden]> writes:
>
>> My hardware setup requires the -P command line option to successfully
>> start a jack server. This works fine when set in qjackctrl (Audio
>> mode: Playback) as long as the dbus option is not selected. However
>> when the dbus option is selected the server hangs on startup. Looking
>> at the qjackctl code and the contents of conf.xml shows that when
>> Playback mode is selected the only affect on the conf.xml parameters
>> is that duplex is set to false, this is exactly the same when the
>> Capture mode is selected so there is no differentiation between
>> Playback and Capture modes in the parameters. This looks like a
>> qjackctl bug, but putting that to one side for the moment as well as
>> presumption that my server hangs because it is not getting clock/data
>> from one of the digital capture ports.
>>
>> I have experimented to see what should be set in the dbus parameters
>> to replicate the -P option. Using jack_control I have tried various
>> combinations of settings for the duplex, playback, capture, inchannels
>> and outchannels parameters, but I have not found one combination that
>> successfully starts the server.
>>
>> My question is, is the replication of the -P parameter possible using
>> the dbus server, and if so what is the magic combination?
> What is the full jackd commandline that works for you?
>
> Are you using the JACK driver for ALSA, right? If so, the driver
> parameter name that matches the jackd`s '-P' is 'playback'. Make sure
> that 'device' parameter is not set. Note that jack_control has no
> command for resetting parameters to their defaults, only for setting
> them. ladiconf can do this though. If you want to reset all parameters,
> delete the conf.xml file and reactivate jackdbus.
>
> jackdbus (and control api) parameters are ordered and the alsa driver
> puts the device parameter after the capture and playback parameters. So
> if you set the device parameter, it will override the playback
> parameter. Quick look into jackd (jack2) code suggests that jackd has
> the same behaviour. so specifying both -P and -d (regardless of the
> order) will cause -P to be ignored.
>
> Here is the relevant code of the alsa driver:
>
> case 'C':
> capture = TRUE;
> if (strcmp (param->value.str, "none") != 0) {
> capture_pcm_name = strdup (param->value.str);
> jack_log("capture device %s", capture_pcm_name);
> }
> break;
>
> case 'P':
> playback = TRUE;
> if (strcmp (param->value.str, "none") != 0) {
> playback_pcm_name = strdup (param->value.str);
> jack_log("playback device %s", playback_pcm_name);
> }
> break;
>
> case 'D':
> playback = TRUE;
> capture = TRUE;
> break;
>
> case 'd':
> playback_pcm_name = strdup (param->value.str);
> capture_pcm_name = strdup (param->value.str);
> jack_log("playback device %s", playback_pcm_name);
> jack_log("capture device %s", capture_pcm_name);
> break;
>
>
> The the internal order of these parameters is:
> * "capture", 'C'
> * "playback", 'P'
> * "device", 'd'
> * "duplex", 'D'
>
The command string that works for me with the command line server is
/usr/bin/jackd -dalsa -dhw:0 -r44100 -p1024 -n2 -P
This is what qjackctrl generates if you select Audio mode "Playback" and
turn dbus support off.
After killing off the pulseaudio server completely I finally managed to
find a set of parameters that would start the dbus server and only
provide playback ports.
For the conf.xml file these look like this,
<driver name="alsa">
<option name="capture">0</option>
<option name="duplex">false</option>
<option name="inchannels">0</option>
</driver>
I also managed to successfully start the server with these parameters
merged into the dbus parameters generated by qjackctl as follows.
<driver name="alsa">
<option name="capture">0</option>
<option name="device">hw:0</option>
<option name="rate">44100</option>
<option name="period">1024</option>
<option name="nperiods">2</option>
<option name="hwmon">false</option>
<option name="hwmeter">false</option>
<option name="duplex">false</option>
<option name="softmode">false</option>
<option name="monitor">false</option>
<option name="dither">n</option>
<option name="inchannels">0</option>
<option name="shorts">false</option>
</driver>
I too have seen a mention somewhere that the equivalent to -P is
"playback", but my experiments seem to suggest otherwise. As the does
the output of the dp command in jack_control
roger@gatekeeper:~/.config/jack$ jack_control dp
--- get driver parameters (type:isset:default:value)
capture: Provide capture ports. Optionally set device
(str:set:none:0)
playback: Provide playback ports. Optionally set device
(str:notset:none:none)
device: ALSA device name (str:notset:hw:0:hw:0)
rate: Sample rate (uint:notset:48000:48000)
period: Frames per period (uint:notset:1024:1024)
nperiods: Number of periods of playback latency
(uint:notset:2:2)
hwmon: Hardware monitoring, if available
(bool:notset:False:False)
hwmeter: Hardware metering, if available
(bool:notset:False:False)
duplex: Provide both capture and playback ports
(bool:set:True:False)
softmode: Soft-mode, no xrun handling
(bool:notset:False:False)
monitor: Provide monitor ports for the output
(bool:notset:False:False)
dither: Dithering mode (char:notset:n:n)
inchannels: Number of capture channels (defaults to hardware
max) (uint:set:0:0)
outchannels: Number of playback channels (defaults to hardware
max) (uint:notset:0:0)
shorts: Try 16-bit samples before 32-bit
(bool:notset:False:False)
input-latency: Extra input latency (frames) (uint:notset:0:0)
output-latency: Extra output latency (frames) (uint:notset:0:0)
midi-driver: ALSA MIDI driver name (seq|raw)
(str:notset:none:none)
roger@gatekeeper:~/.config/jack$
It says that the playback parameter has a type of string and a default
value when not set of the string "none". According to my reading of what
jack_control is saying the string value of the parameter has both to
convey whether playback ports are to be provided or not be provided and
optionally the name of the device to be used. It does not have any
affect on whether capture ports are provided. My experiments seem to
show that the unset value "none" means provide playback ports and use
the device name from the device parameter. So I guessed that the
similar thing applied to the capture parameter and that a value of 0
(zero) meant do not provide any ports. When I set capture to zero duplex
to false and inchannels to zero it finally burst in life and did what I
wanted which was to provide the system maximum of playback ports and
zero capture ports as the command line server does when the -P option is
specified.
roger@gatekeeper:~/.config/jack$ jack_lsp
system:playback_1
system:playback_2
system:playback_3
system:playback_4
system:playback_5
system:playback_6
system:playback_7
system:playback_8
However this still leaves me with the problem that qjacktrl cannot be
configured to generate these parameters. When the the Audio mode of
Playback is selected the input device (used for the capture paramteter),
output (used for the playback parameter) and input channels (used for
the inchannels parameter) are grayed out, and because they are in this
state reset commands for them are sent to dbus.
I guess if I want to use qjackctl I will have to go back to figuring why
the server hangs when capture ports are specified on my system that has
a standard onboard nVidia HDA chipset. But that is for another day.
Roger
1321993938.12894_0.ltw:2,a <4ECC0674.5010102 at beardandsandals dot co dot uk>