Bug 167 - Qsampler shouldn't allow to adjust sample rate when running with JACK
Summary: Qsampler shouldn't allow to adjust sample rate when running with JACK
Alias: None
Product: QSampler
Classification: Unclassified
Component: qsampler (show other bugs)
Version: SVN Trunk
Hardware: PC Linux
: P5 normal
Assignee: Rui Nuno Capela
Depends on:
Reported: 2012-01-06 19:42 CET by Frank Neumann
Modified: 2014-01-26 19:53 CET (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Frank Neumann 2012-01-06 19:42:45 CET
Running LinuxSampler/QSampler against JACK, when I open the "Devices" dialog and click on the "Audio Devices" item on the left side, the widgets on the right side allow to modify the JACK sample rate although this doesn't make sense (as far as I know) when jackd is already running. In fact, if I modify that setting and create a new JACK device, it receives the standard jackd sample rate.

I suggest that this item be disabled ("ghosted") in the GUI when running against JACK.
Comment 1 Christian Schoenebeck 2013-05-31 20:37:28 CEST
Yes, makes sense. Since the JACK API currently does not allow to change the sample rate after jackd has been launched. Surprisingly though, since the sample rate can be adjusted during runtime of jackd.
Comment 2 Christian Schoenebeck 2014-01-26 19:53:12 CET
This issue probably has to be addressed in the sampler's network protocol first. Currently there is only one parameter information field related to this issue, called "FIX":

http://www.linuxsampler.org/api/draft-linuxsampler-protocol.html#GET%20AUDIO_OUTPUT_DRIVER_PARAMETER INFO

If a parameter is FIX=false it means that parameter can be altered at any time by the user. And FIX=true currently means a user chosen value for this parameter may be given at device creation (driver instantiation) time, however may not be altered by the user after the device was created.

But for this particular issue here, we would need to address a third case: a parameter which is always read-only, which can neither be given at device creation time, nor altered at runtime afterwards.

I am currently unresolved how to address this in best way. I currently see two options:

1) Adding a new parameter info field to LSCP like "READ_ONLY". READ_ONLY=true would then mean that the given parameter is just for informational purposes, but may not be given or altered at any time by the user. However having "FIX" and "READ_ONLY" would make this part of the protocol a bit unclean and unintuitive.

or alternative:

2) Not exposing the existence of those particular driver parameters (via LSCP) before the device has been created. So in this case, the SAMPLERATE parameter would for example be shown to the frontend (i.e. QSampler) by the sampler *only* after the JACK device has been created. Disadvantage would be that i.e. QSampler would not know anything about the existence of i.e. parameter SAMPLERATE before it created a JACK device. Could that bad for some kind of parameter now or in future? I am not sure ... For example a user might have 2 sound cards in his box, one with hardware given 44.1kHz and the other one with 96kHz. At the moment, with the current protocol (i.e. with driver "ALSA") one could show him that particular difference of the two sound cards before selecting one of them for usage in the sampler.