Re: [LAU] Problems with sample rate and recordings (Mackie onyx > 1640-i < Firewire > Debian )
27 Feb
2015
27 Feb
'15
4:07 p.m.
Date: Thu, 26 Feb 2015 17:18:35 +0100
From: sub <subvertao(a)inventati.org>
Message-ID: <54EF475B.8040601(a)inventati.org>
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.
--
Chris Caudle
2 Mar
2 Mar
11:04 p.m.
New subject: Problems with sample rate and recordings (Mackie onyx > 1640-i < Firewire > Debian )
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
On 02/27/2015 05:06 PM, Chris Caudle wrote:
Date: Thu, 26
Feb 2015 17:18:35 +0100 From: sub
<subvertao(a)inventati.org> Message-ID:
<54EF475B.8040601(a)inventati.org> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJU9OxdAAoJEHdKSBXNuVOyElcQAMOd4tYrZ3oQI9+rC6FtD6we
23VOUW/f357oJkS2V0fXaO0RYpMQUyKw4FvFL6FpN+ixoskUbSwdrwXHao7F04Fx
4OQrncVSLo4GmKDt/inTZ678ki/RXUEC2G3ToEZPL4x9bmaWN35YVVMmLsMh4fir
MeWmUVDOuJQdhmWkcndqftkQ5SbWPmOvZ+uSmyu3tPM2x8H13iMMQhl9S83cGy2A
ew+TKdD7Rzeu8uPgDrqgdKIjuX+DIs0aZsueL3EvycP7/Szdv++i6+3JOEQ1RV3/
sUZutqIOSte82CeG78tKNtro5ezpXJoMkR/tgBl4QQ9ZQc+rKwtUBzTB0uv7unRC
ETOtzLUko4xAI9Cp+YlxdayTmo9S5cDazlKTkM6pIGOo6ZBnynVydIZsyOXgsOdt
tSu9kDRQezS6x/GpTB5SOVZij0LnEfFF0RXkqLB3riNleYKMGNXec/1YJfW6rtb8
Eds2aB48vwAVdPzAF0AF7IWiuPfNwiUsHMFL92N585teNCqYu3Th7CujNKQllOtF
AG0pdtIb8tpxTCoMuwm4LzQvv3hf4Dnl9f6zMjbZ2WUUqTVL3MTYqXtMde+VyJ9w
dfafFWL9hlj6q7irv06bxDMVFNugLLL2jlLcphYIUTJIDjQyzblukZNQVtxoj5KH
vVGx6W92QG8eo7ZRhB2S
=TcU7
-----END PGP SIGNATURE-----
11:17 p.m.
New subject: Problems with sample rate and recordings (Mackie onyx > 1640-i < Firewire > Debian )
On Tue, 03 Mar 2015 00:03:57 +0100, sub wrote:
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 ;).
3 Mar
3 Mar
12:04 a.m.
New subject: Problems with sample rate and recordings (Mackie onyx > 1640-i < Firewire > Debian )
On Mon, March 2, 2015 5:03 pm, sub wrote:
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).
--
Chris Caudle
8:58 a.m.
New subject: Problems with sample rate and recordings (Mackie onyx > 1640-i < Firewire > Debian )
Where do you get that information from? Jackctl?
On 03/03/2015 01:03 AM, Chris Caudle wrote:
On Mon, March 2, 2015 5:03 pm, sub wrote:
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).
9:22 a.m.
New subject: Problems with sample rate and recordings (Mackie onyx > 1640-i < Firewire > Debian )
On 03/03/2015 01:03 AM, Chris Caudle wrote:
> 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.
9:34 a.m.
New subject: Problems with sample rate and recordings (Mackie onyx > 1640-i < Firewire > Debian )
Wait, do not mix different subjects.
Alsa and jack are not the same, please i am looking for support on a
specifical problem.
On 03/03/2015 10:22 AM, Ralf Mardorf wrote:
On 03/03/2015 01:03 AM, Chris Caudle wrote:
> 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
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
9:51 a.m.
New subject: Problems with sample rate and recordings (Mackie onyx > 1640-i < Firewire > Debian )
On Tue, 03 Mar 2015 10:34:33 +0100, sub wrote:
Alsa and jack are not the same, please i am looking for
support on a
specifical problem.
On Thu, 26 Feb 2015 17:18:35 +0100, sub wrote:
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 ;) ...
On 03/03/2015 10:22 AM, Ralf Mardorf wrote:
>> On 03/03/2015 01:03 AM, Chris Caudle wrote:
>>> 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
10:46 p.m.
New subject: Problems with sample rate and recordings (Mackie onyx > 1640-i < Firewire > Debian )
On Tue, March 3, 2015 3:22 am, Ralf Mardorf wrote:
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.…
On 03/03/2015
01:03 AM, Chris Caudle wrote:
> 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.
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.
--
Chris Caudle
4 Mar
4 Mar
9:50 a.m.
New subject: Problems with sample rate and recordings (Mackie onyx > 1640-i < Firewire > Debian )
On 03/03/2015 11:46 PM, Chris Caudle wrote:
On Tue, March 3, 2015 3:22 am, Ralf Mardorf wrote:
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.…
This sounds interesting.
But how could i use this parameter? Any specifical command i should use
into the shell?
On
03/03/2015 01:03 AM, Chris Caudle wrote:
> for nearly every device the driver should be able to set the
> sample rate
But by what way can the sample rate be set?
5:13 p.m.
New subject: Problems with sample rate and recordings (Mackie onyx > 1640-i < Firewire > Debian )
On Wed, March 4, 2015 3:50 am, sub wrote:
...
> By using the snd_pcm_hw_params_set_rate_near ()
ALSA function.
...
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
3 Mar
3 Mar
9:30 p.m.
New subject: Problems with sample rate and recordings (Mackie onyx > 1640-i < Firewire > Debian )
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.
--
Chris
9:58 p.m.
New subject: Problems with sample rate and recordings (Mackie onyx > 1640-i < Firewire > Debian )
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.
10:25 p.m.
New subject: Problems with sample rate and recordings (Mackie onyx > 1640-i < Firewire > Debian )
On Tue, March 3, 2015 3:58 pm, sub wrote:
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.
--
Chris Caudle
10:29 p.m.
New subject: Problems with sample rate and recordings (Mackie onyx > 1640-i < Firewire > Debian )
This has been done by my collegue.
http://subversion.ffado.org/ticket/388
On 03/03/2015 11:25 PM, Chris Caudle wrote:
On Tue, March 3, 2015 3:58 pm, sub wrote:
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.
3346
days inactive
3351
days old
linux-audio-user@lists.linuxaudio.org
14 comments
3 participants
participants (3)
-
Chris Caudle -
Ralf Mardorf -
sub