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

[Chris Caudle]

Date: Thu, 26 Feb 2015 17:18:35 +0100
i received a mail from the band in which they tell me
that the mix is faster and at a higher pitch than the
audio they recorded through a video camera at the
concert.

Video cameras record at 48k rate, so someone will need to rate convert.
Either the camera audio will need to be converted to 44.1k or your audio
will need to be converted to 48k.
Which you choose probably does not matter, but everyone involved needs to
know and agree on the chosen project sample rate.
If the final output will be a video then converting every thing to 48k is
probably the easiest choice. If the final output will be a CD (or audio
only files) then probably 44.1k is the easiest choice. If you will have
both a video and audio only files, my choice would be working in 48k and
then sample rate convert the final mix to 44.1k for CD.

[sub]

The problem is not the sample frequency of the final audio mix.
What i think is happens here is that most probably the Onyx and the
debian recorder are not using the same sample rate at the time of
recording, so the samples that are taken every second on the mixer
(probably at a frequency of 48Khz?) are being spreaded over a 44.1Khz
file, generating a 44.1Khz audio file that is longer in time, with a
consequent change in pitch. Now, I have no information about what
sample frequency the onyx 1640i is synched at, since the firewire
module used by jackd does not "see" the onyx as an audio card, and
doesn't seem to have the possibility to set the sample frequency of
the mixer through jackctl. What i think it's happening is that jackd
is simply setting its own sample rate, and not synching the mixer or
being synched by the mixer.

In pro-audio environments these kind of problems are normally avoided
by using a word clock coax cable between the two devices, or by using
AES-EBU connections (that carry the word clock on one pin, and
therefore synch all devices in the chain automatically) but i ignore
how this is achieved with the only use of firewire (no word clock coax
connectors on the devices either here). The drivers for Mac OS and
Windows provided with the onyx give at least the possibility to
monitor and set the sample rate the onyx synchs to, so that an
operator can at least choose safely at what sample rate to record
(although this does not, in my experience of digital audio, give the
guarantee of a perfect synch). Here i don't even get a debug line
about the onyx synch to sample rate in the jackctl log file, so what i
can come to is only assumptions.

Playing mp3s (so 44.1Khz files) with mocp through the onyx by using
jackctl has the effect of the songs improvisely changing pitch and
speed, without actually having any change in what jackctl shows as a
sample rate in its panel. This means obviously that the onyx is
switching between different synchs without jackd noticing it.

Post by Chris Caudle

Date: Thu, 26 Feb 2015 17:18:35 +0100 From: sub
in which they tell me that the mix is faster and at a higher
pitch than the audio they recorded through a video camera at the
concert.

Video cameras record at 48k rate, so someone will need to rate
convert. Either the camera audio will need to be converted to 44.1k
or your audio will need to be converted to 48k. Which you choose
probably does not matter, but everyone involved needs to know and
agree on the chosen project sample rate. If the final output will
be a video then converting every thing to 48k is probably the
easiest choice. If the final output will be a CD (or audio only
files) then probably 44.1k is the easiest choice. If you will
have both a video and audio only files, my choice would be working
in 48k and then sample rate convert the final mix to 44.1k for CD.

[Ralf Mardorf]

Post by sub
In pro-audio environments these kind of problems are normally avoided
by using a word clock coax cable between the two devices

Actually home recording equipment that can be used with Linux sometimes
provide BNC wordclock too ;).

[Chris Caudle]

Post by sub
Now, I have no information about what
sample frequency the onyx 1640i is synched at, since the firewire
module used by jackd does not "see" the onyx as an audio card, and
doesn't seem to have the possibility to set the sample frequency of
the mixer through jackctl.

That would be a bug in the firewire driver for handling that device, the
audio device should always report the sample rate being used, and for
nearly every device the driver should be able to set the sample rate
(there are a few which have a hardware switch to set the rate, those can
only report the rate set by the hardware).

[sub]

Where do you get that information from? Jackctl?

Post by Chris Caudle

Post by sub
Now, I have no information about what
sample frequency the onyx 1640i is synched at, since the firewire
module used by jackd does not "see" the onyx as an audio card, and
doesn't seem to have the possibility to set the sample frequency of
the mixer through jackctl.

That would be a bug in the firewire driver for handling that device, the
audio device should always report the sample rate being used, and for
nearly every device the driver should be able to set the sample rate
(there are a few which have a hardware switch to set the rate, those can
only report the rate set by the hardware).

[Ralf Mardorf]

for nearly every device the driver should be able to set the
sample rate

But by what way can the sample rate be set?

I've got PCI cards were jackd is able to set all available sample
rates, but for my PCIe card just some sample rates can directly be set
by jackd, for some sample rates I need to do it by alsamixer, before I
start jackd.

[sub]

Wait, do not mix different subjects.
Alsa and jack are not the same, please i am looking for support on a
specifical problem.

Post by Ralf Mardorf

for nearly every device the driver should be able to set the
sample rate

But by what way can the sample rate be set?
I've got PCI cards were jackd is able to set all available sample
rates, but for my PCIe card just some sample rates can directly be set
by jackd, for some sample rates I need to do it by alsamixer, before I
start jackd.
_______________________________________________
Linux-audio-user mailing list
http://lists.linuxaudio.org/listinfo/linux-audio-user

[Ralf Mardorf]

Post by sub
Alsa and jack are not the same, please i am looking for support on a
specifical problem.
When i record multitrack audio using Ardour and jackd

So I'm aware that you aren't using the ALSA backend for your firewire
device ;) ...

Post by sub

Post by Ralf Mardorf

for nearly every device the driver should be able to set the
sample rate

But by what way can the sample rate be set?
I've got PCI cards were jackd is able to set all available sample
rates, but for my PCIe card just some sample rates can directly be
set by jackd, for some sample rates I need to do it by alsamixer,
before I start jackd.

... but perhaps there's something else that needs to be used to set the
sample rate, before you can start jackd. I don't know, but since nobody
is able to give you the correct answer, brainstorming might be helpful.
I only wanted to point out that jackd not always can be used to set the
hardware's sample rate.

Regards,
Ralf

[Chris Caudle]

Post by Ralf Mardorf

for nearly every device the driver should be able to set the
sample rate

But by what way can the sample rate be set?

By using the snd_pcm_hw_params_set_rate_near () ALSA function. That is
what jack2 uses.

http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html#ga39124280d06ce63092a77e3f25ddd6ee

Post by Ralf Mardorf
I've got PCI cards were jackd is able to set all available sample
rates, but for my PCIe card just some sample rates can directly be set
by jackd, for some sample rates I need to do it by alsamixer, before I
start jackd.

That is very odd. Glancing at the alsamixer source I do not see any
explicit sample rate controls, it appears to just get a list of supported
controls from the card driver. I don't know why alsamixer would be able
to find a sample rate control when hw_params_set_rate_near() did not work
properly.
You would probably need to discuss with the developer of the driver for
that particular card.

[sub]

Post by Chris Caudle

Post by Ralf Mardorf

for nearly every device the driver should be able to set the
sample rate

But by what way can the sample rate be set?

By using the snd_pcm_hw_params_set_rate_near () ALSA function. That is
what jack2 uses.
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html#ga39124280d06ce63092a77e3f25ddd6ee

This sounds interesting.
But how could i use this parameter? Any specifical command i should use
into the shell?

[Chris Caudle]

On Wed, March 4, 2015 3:50 am, sub wrote:
...

Post by sub

Post by Chris Caudle
By using the snd_pcm_hw_params_set_rate_near () ALSA function.

...

Post by sub
This sounds interesting.
But how could i use this parameter? Any specifical command i should use
into the shell?

That function is in the ALSA library, so not directly applicable (you
mentioned using the firewire backend with JACK, so I assume you are using
FFADO directly and not the new ALSA support for Firewire devices).
I looked through the FFADO sources and did not see something directly
equivalent, but it really isn't necessary, you should know what sample
rates your device supports and just set the correct rate. I think the
ALSA function is just there to support multiple audio devices where you
may switch from one audio device to another which does not support the
same capabilities. That doesn't really work in a production setting since
for example the Ardour project rate would then no longer match the running
sample rate. More for general desktop use.

Probably the most useful items from FFADO would be ffado-mixer to show the
current sample rate settings of the hardware, or let you set a particular
sample rate, and the ffado-test utilities to verify operation apart from
jackd.

[Chris Caudle]

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.

[sub]

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.

Post by Chris Caudle

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.
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
32bit integer little-endian
Tue Mar 3 14:47:03 2015: ALSA: use 2 periods for capture
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
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
32bit integer little-endian
Tue Mar 3 14:57:15 2015: ALSA: use 2 periods for capture
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
$ 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.

[Chris Caudle]

Post by sub
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 locked at.

Then you should check with the FFADO developers, that seems to be a
problem with the driver to device interaction.

[sub]

This has been done by my collegue.
http://subversion.ffado.org/ticket/388

Post by Chris Caudle

Post by sub
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 locked at.

Then you should check with the FFADO developers, that seems to be a
problem with the driver to device interaction.