[LAU] Problems with sample rate and recordings (Mackie onyx > 1640-i < Firewire > Debian )

sub subvertao at inventati.org
Tue Mar 3 21:58:25 UTC 2015


Thank you for this information, this will surely help debugging.

But, the problem i am encountering tells me that what sample rate
jackctl locks to is not in anyway related to what sample rate my onyx
1640-i is loked at. In other words, the sample i you decide jack will
use is not determining my Mackie onyx to switch to that sample rate
mode. The jack_samplerate command is telling you what sample rate jack
is using, but if my onyx is locked at another sample rate, the bistream
from the onyx will be wrongly interpreted. In my situation i set jack to
use 44.1 and i can't be sure if the onyx is at 48 or 96 or 44.1.
I recorded a live at 44.1 without any error from jack and the audio is
at 44.1 but is faster and at a higher pitch than the original.

On 03/03/2015 10:30 PM, Chris Caudle wrote:
> On Tue, March 3, 2015 2:58 am, sub wrote:
>> Where do you get that information [hardware sample rate] from? Jackctl?
> 
> Jackctl (I assume you mean qjackctl application?) is just passing through
> the information from the jack server.  You can see most easily by watching
> the output on the command line when starting jack by hand, but qjackctl
> also has a method to display the output by clicking on the "Messages"
> button to display the output from the server.
> 
> This is an example output from a jack instance I just started:
> Tue Mar  3 14:47:03 2015: Acquired audio card Audio1
> Tue Mar  3 14:47:03 2015: creating alsa driver ...
> hw:M2496|hw:M2496|1024|2|44100|0|0|nomon|swmeter|-|32bit
> Tue Mar  3 14:47:03 2015: configuring for 44100Hz, period = 1024 frames
> (23.2 ms), buffer = 2 periods
> Tue Mar  3 14:47:03 2015: ALSA: final selected sample format for capture:
> 32bit integer little-endian
> Tue Mar  3 14:47:03 2015: ALSA: use 2 periods for capture
> Tue Mar  3 14:47:03 2015: ALSA: final selected sample format for playback:
> 32bit integer little-endian
> Tue Mar  3 14:47:03 2015: ALSA: use 2 periods for playback
> 
> This is the line which describes the attempt to set the hardware
> configuration:
> 
> configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods
> 
> This is the output from the qjackctl message window when I select 192k
> 
> Tue Mar  3 14:57:15 2015: Acquired audio card Audio1
> Tue Mar  3 14:57:15 2015: creating alsa driver ...
> hw:M2496|hw:M2496|1024|2|192000|0|0|nomon|swmeter|-|32bit
> Tue Mar  3 14:57:15 2015: configuring for 192000Hz, period = 1024 frames
> (5.3 ms), buffer = 2 periods
> Tue Mar  3 14:57:15 2015: ALSA: final selected sample format for capture:
> 32bit integer little-endian
> Tue Mar  3 14:57:15 2015: ALSA: use 2 periods for capture
> Tue Mar  3 14:57:15 2015: ALSA: final selected sample format for playback:
> 32bit integer little-endian
> 
> That interface card does not actually support 192k sample rate, so 96k was
> chosen as the closest available rate, but that was not actually displayed
> in the messages window.  The qjackctl status window did however show the
> actual sample rate being used.
> 
> creating alsa driver ...
> hw:M2496|hw:M2496|1024|2|192000|0|0|nomon|swmeter|-|32bit
> configuring for 192000Hz, period = 1024 frames (5.3 ms), buffer = 2 periods
> ALSA: final selected sample format for capture: 32bit integer little-endian
> 
> The jack_samplerate application can be used to display the currently used
> samplerate of the running server:
> $ jack_samplerate
> 96000
> 
> So not quite as simple as it could be, it would be nicer if the jackd
> server actually printed to the console the chosen sample rate, but you
> have to get a jack client such as jack_samplerate or qjackctl to display
> the running sample rate for you.
> 
> 
> 



More information about the Linux-audio-user mailing list