Hi phofman,
my point is, that -b 32 and hw:0,0 are *not* working currently!
My aim with sox is not to do any conversion, just use the 24bit ADC and the 24bbit DAC in a loop (full duplex mode)
Rüdiger
my point is, that -b 32 and hw:0,0 are *not* working currently!
My aim with sox is not to do any conversion, just use the 24bit ADC and the 24bbit DAC in a loop (full duplex mode)
Rüdiger
Try the recording with
The -v (verbose) parameter will tell you the actual hw parameters of your sound card and what transformations the plug plugin has to perform to achieve your required S24_3LE format (i.e. 24 bits in 3 bytes). You can post the command output here.
Code:
arecord -v -f S24_3LE -c 2 -D plughw:0 input.wav
The -v (verbose) parameter will tell you the actual hw parameters of your sound card and what transformations the plug plugin has to perform to achieve your required S24_3LE format (i.e. 24 bits in 3 bytes). You can post the command output here.
This is the output:
I do not quite understand this output. It looks as if a 24bit 8000Hz stream would be transposed to 24bit and 44.1kHz. If I playback that file (input.wav)
aplay states
Rüdiger
Code:
arecord -v -f S24_3LE -c 2 -D plughw:0 input.wav
Aufnahme: WAVE 'input.wav' : Signed 24 bit Little Endian in 3bytes, Rate: 8000 Hz, stereo
Plug PCM: Rate conversion PCM (44100, sformat=S32_LE)
Converter: linear-interpolation
Protocol version: 10002
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S24_3LE
subformat : STD
channels : 2
rate : 8000
exact rate : 8000 (8000/1)
msbits : 24
buffer_size : 1486
period_size : 185
period_time : 23219
tstamp_mode : NONE
period_step : 1
avail_min : 185
period_event : 0
start_threshold : 1
stop_threshold : 1486
silence_threshold: 0
silence_size : 0
boundary : 194772992
Slave: Hardware PCM card 0 'RME Digi96/8 PST' device 0 subdevice 0
Its setup is:
stream : CAPTURE
access : MMAP_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 32
buffer_size : 8192
period_size : 1024
period_time : 23219
tstamp_mode : NONE
period_step : 1
avail_min : 1024
period_event : 0
start_threshold : 6
stop_threshold : 8192
silence_threshold: 0
silence_size : 0
boundary : 1073741824
appl_ptr : 0
hw_ptr : 0
I do not quite understand this output. It looks as if a 24bit 8000Hz stream would be transposed to 24bit and 44.1kHz. If I playback that file (input.wav)
aplay states
Code:
aplay input.wav
Wiedergabe: WAVE 'input.wav' : Signed 24 bit Little Endian in 3bytes, Rate: 8000 Hz, stereo
Rüdiger
Very well, thanks for the outputs.
In the first case you told arecord to capture a 24bit stereo file. You did not specify the samplerate and arecord picked the default - 8000 Hz. The request went through the plug plugin (see the Plug PCM line) which matched your request with the card capabilities, as reported by its driver.
The lowest rate your card supports is 44100. The plug plugin must provide a conversion from this rate to your requested 8000Hz. BTW your default resampling method is rather low quality (linear-interpolation), you may want to play with defaults.pcm.rate_converter , e.g. Advanced Linux Sound System user questions
The card does not support native 24bits. Well, the actual ADC and DAC do, but the card PCI controller works at 32bits, as is the case with many cards. Therefore the plug must convert from 32bits to 24bits, your requested format.
This produced your requested 8/24 file. Your second example plays this file back. Since you did not specify the actual device, the "default" was used. If you invoke aplay with the -v option (verbose), we will be able to see what the alsa-lib stack did with your request, just as we did with arecord -v. Without the verbose log we do not know how your default device is defined, whether it goes through pulseaudio, dmix, plain plughw, etc.
In the first case you told arecord to capture a 24bit stereo file. You did not specify the samplerate and arecord picked the default - 8000 Hz. The request went through the plug plugin (see the Plug PCM line) which matched your request with the card capabilities, as reported by its driver.
The lowest rate your card supports is 44100. The plug plugin must provide a conversion from this rate to your requested 8000Hz. BTW your default resampling method is rather low quality (linear-interpolation), you may want to play with defaults.pcm.rate_converter , e.g. Advanced Linux Sound System user questions
The card does not support native 24bits. Well, the actual ADC and DAC do, but the card PCI controller works at 32bits, as is the case with many cards. Therefore the plug must convert from 32bits to 24bits, your requested format.
This produced your requested 8/24 file. Your second example plays this file back. Since you did not specify the actual device, the "default" was used. If you invoke aplay with the -v option (verbose), we will be able to see what the alsa-lib stack did with your request, just as we did with arecord -v. Without the verbose log we do not know how your default device is defined, whether it goes through pulseaudio, dmix, plain plughw, etc.
Okay:
From this output it seems that 32k is the lowest sample rate my card is capable of.
What I don't get from your explanation above: if my card interface reads 32bits nativly and the ADC/DAC work at 24bit, shouldn't the conversion not be done in hardware without any software drivers involved? (Since RME is proclaiming to even mix channels and so forth in hardware?)
Rüdiger
Code:
aplay -v input.wav
Wiedergabe: WAVE 'input.wav' : Signed 32 bit Little Endian, Rate: 8000 Hz, stereo
Plug PCM: Rate conversion PCM (32000, sformat=S32_LE)
Converter: linear-interpolation
Protocol version: 10002
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 8000
exact rate : 8000 (8000/1)
msbits : 32
buffer_size : 2048
period_size : 256
period_time : 32000
tstamp_mode : NONE
period_step : 1
avail_min : 256
period_event : 0
start_threshold : 2048
stop_threshold : 2048
silence_threshold: 0
silence_size : 0
boundary : 268435456
Slave: Hardware PCM card 0 'RME Digi96/8 PST' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 32000
exact rate : 32000 (32000/1)
msbits : 32
buffer_size : 8192
period_size : 1024
period_time : 32000
tstamp_mode : NONE
period_step : 1
avail_min : 1024
period_event : 0
start_threshold : 8192
stop_threshold : 8192
silence_threshold: 0
silence_size : 0
boundary : 1073741824
appl_ptr : 0
hw_ptr : 0
What I don't get from your explanation above: if my card interface reads 32bits nativly and the ADC/DAC work at 24bit, shouldn't the conversion not be done in hardware without any software drivers involved? (Since RME is proclaiming to even mix channels and so forth in hardware?)
Rüdiger
One issue seems to be:
arecord does not switch the card to other samplerates, rather uses sample rate conversion.
Conversly, mpd switches the card to the desired sample rate.
Look at the output if the card was running with 96k previously:
And now if the mpd played a 16/44.1 file before:
Rüdiger
EDIT: and I still don't get why the same card with the same OS does not work with hw:0,0 and sox anymore in another machine!
arecord does not switch the card to other samplerates, rather uses sample rate conversion.
Conversly, mpd switches the card to the desired sample rate.
Look at the output if the card was running with 96k previously:
Code:
arecord -v -f S32_LE -c 2 -r 96000-D hw:0,0 input.wav
Aufnahme: WAVE 'hw:0,0' : Signed 32 bit Little Endian, Rate: 96000 Hz, stereo
Plug PCM: Hardware PCM card 0 'RME Digi96/8 PST' device 0 subdevice 0
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 96000
exact rate : 96000 (96000/1)
msbits : 32
buffer_size : 8192
period_size : 1024
period_time : 10666
tstamp_mode : NONE
period_step : 1
avail_min : 1024
period_event : 0
start_threshold : 1
stop_threshold : 8192
silence_threshold: 0
silence_size : 0
boundary : 1073741824
appl_ptr : 0
hw_ptr : 0
Code:
# arecord -v -f S32_LE -c 2 -r 96000-D hw:0,0 input.wav
Aufnahme: WAVE 'hw:0,0' : Signed 32 bit Little Endian, Rate: 96000 Hz, stereo
Plug PCM: Rate conversion PCM (44100, sformat=S32_LE)
Converter: linear-interpolation
Protocol version: 10002
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 96000
exact rate : 96000 (96000/1)
msbits : 32
buffer_size : 17832
period_size : 2229
period_time : 23219
tstamp_mode : NONE
period_step : 1
avail_min : 2229
period_event : 0
start_threshold : 1
stop_threshold : 17832
silence_threshold: 0
silence_size : 0
boundary : 1168637952
Slave: Hardware PCM card 0 'RME Digi96/8 PST' device 0 subdevice 0
Its setup is:
stream : CAPTURE
access : MMAP_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 32
buffer_size : 8192
period_size : 1024
period_time : 23219
tstamp_mode : NONE
period_step : 1
avail_min : 1024
period_event : 0
start_threshold : 0
stop_threshold : 8192
silence_threshold: 0
silence_size : 0
boundary : 1073741824
appl_ptr : 0
hw_ptr : 0
Rüdiger
EDIT: and I still don't get why the same card with the same OS does not work with hw:0,0 and sox anymore in another machine!
Last edited:
From this output it seems that 32k is the lowest sample rate my card is capable of.
Yes it is, at least the driver tells the upper levels so: git.alsa-project.org Git - alsa-kmirror.git/blob - pci/rme96.c
What I don't get from your explanation above: if my card interface reads 32bits nativly and the ADC/DAC work at 24bit, shouldn't the conversion not be done in hardware without any software drivers involved? (Since RME is proclaiming to even mix channels and so forth in hardware?)
The PCI side of the interface runs at 32bits. You requested 24 bits. That is 24bits on the PCI side of the interface, thus the conversion in software. Formats on the soundcard side of the interface are irrelevant to your software. E.g. there could be 32bit DACs with the same effect.
arecord does not switch the card to other samplerates, rather uses sample rate conversion.
Code:arecord -v -f S32_LE -c 2 -r 96000-D hw:0,0 input.wav Aufnahme: WAVE 'hw:0,0' : Signed 32 bit Little Endian, Rate: 96000 Hz, stereo Plug PCM: Hardware PCM card 0 'RME Digi96/8 PST' device 0 subdevice 0 ....
Well, you specified hw:0, yet the plug plugin kicked in. Is not that weird? I guess the reason is you did not put a space between your samplerate definition and the -D parameter. I am pretty sure your arecord used the default param as a result, ignoring your incorrect device specification.
And the "stuck" samplerate? Does not this particular soundcard support hardware mixing? If so, my guess is you left MPD running when trying your second arecord test. The card was switched to 44100 by MPD, the card was still open by MPD, as a result it was locked at 44100 and could not switch to 96000, you did not use hw:0 but the default via plug plugin (no space -D again), the plug plugin had to resample to the fixed samplerate of 44100. That is my guess, you can easily verify by making sure the device is not opened by any other process by running
sudo lsof /dev/snd/*
I would guess if you used hw:0 correctly, you would have received "Incorrect parameter" error as the samplerate would have been incompatible.
I still don't get why the same card with the same OS does not work with hw:0,0 and sox anymore in another machine!
Any details? It may not be the first sound card (i.e. hw:0) anymore, for example.
The card was switched to 44100 by MPD, the card was still open by MPD, as a result it was locked at 44100 and could not switch to 96000
This is not the case, see output with corrected space before -D:
Code:
arecord -v -f S32_LE -c 2 -r 96000 -D hw:0,0 input.wav
Aufnahme: WAVE 'input.wav' : Signed 32 bit Little Endian, Rate: 96000 Hz, stereo
Warnung: Rate ist nicht exakt (angefordert: 96000 Hz, unterstützt: 44100 Hz)
probieren Sie bitte das plug-Plugin:
Hardware PCM card 0 'RME Digi96/8 PST' device 0 subdevice 0
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 32
buffer_size : 8192
period_size : 1024
period_time : 23219
tstamp_mode : NONE
period_step : 1
avail_min : 1024
period_event : 0
start_threshold : 1
stop_threshold : 8192
silence_threshold: 0
silence_size : 0
boundary : 1073741824
appl_ptr : 0
hw_ptr : 0
Any details? It may not be the first sound card (i.e. hw:0) anymore, for example.
hw:0,0 is correct (see above as well). On the previous machine I ran
Code:
sox -b 32 -t alsa hw:0,0 -r 96000 -t alsa hw:0,0 (+some biquad commands)
Code:
sox FAIL formats: can't open input `hw:0,0': select_format error: Operation not permitted
Rüdiger
Last edited:
I try to explain one more time:
The state of the soundcard is 16/44.1 when I type and get:
I hope it's clear now?
The state of the soundcard is 16/44.1 when I type and get:
Code:
arecord -v -f S32_LE -c 2 -r 96000 -D hw:0,0 input.wav
Aufnahme: WAVE 'input.wav' : Signed 32 bit Little Endian, Rate: 96000 Hz, stereo
Warnung: Rate ist nicht exakt (angefordert: 96000 Hz, unterstützt: 44100 Hz)
probieren Sie bitte das plug-Plugin:
Hardware PCM card 0 'RME Digi96/8 PST' device 0 subdevice 0
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 32
buffer_size : 8192
period_size : 1024
period_time : 23219
tstamp_mode : NONE
period_step : 1
avail_min : 1024
period_event : 0
start_threshold : 1
stop_threshold : 8192
silence_threshold: 0
silence_size : 0
boundary : 1073741824
appl_ptr : 0
hw_ptr : 0
^CAbbruch durch Signal Unterbrechung ...
EG-Server musik # aplay -v -r 96000 -f S32_LE -c 2 -D hw:0,0 hartmann.wav
Wiedergabe: Rohdaten 'hartmann.wav' : Signed 32 bit Little Endian, Rate: 96000 Hz, stereo
Hardware PCM card 0 'RME Digi96/8 PST' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 96000
exact rate : 96000 (96000/1)
msbits : 32
buffer_size : 8192
period_size : 1024
period_time : 10666
tstamp_mode : NONE
period_step : 1
avail_min : 1024
period_event : 0
start_threshold : 8192
stop_threshold : 8192
silence_threshold: 0
silence_size : 0
boundary : 1073741824
appl_ptr : 0
hw_ptr : 0
^CAbbruch durch Signal Unterbrechung ...
EG-Server musik # arecord -v -f S32_LE -c 2 -r 96000 -D hw:0,0 input.wav
Aufnahme: WAVE 'input.wav' : Signed 32 bit Little Endian, Rate: 96000 Hz, stereo
Hardware PCM card 0 'RME Digi96/8 PST' device 0 subdevice 0
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 96000
exact rate : 96000 (96000/1)
msbits : 32
buffer_size : 8192
period_size : 1024
period_time : 10666
tstamp_mode : NONE
period_step : 1
avail_min : 1024
period_event : 0
start_threshold : 1
stop_threshold : 8192
silence_threshold: 0
silence_size : 0
boundary : 1073741824
appl_ptr : 0
hw_ptr : 0
I hope it's clear now?
OK, it looks better now without the plug plugin 🙂
Before going into some further investigation, I need to see output of the lsof command when recording while you get that message about hardware supporting 44100Hz only. I really want to make sure there is no other process accessing the card at that moment, typically pulseaudio which AFAIK runs at 44100 by default. And please add contents of /proc/asound/card0/rme96 during the recording-at-44100 phase. It will tell e.g. which input you are using since each input type handles the supported sample rates differently, according to the driver source code.
Before going into some further investigation, I need to see output of the lsof command when recording while you get that message about hardware supporting 44100Hz only. I really want to make sure there is no other process accessing the card at that moment, typically pulseaudio which AFAIK runs at 44100 by default. And please add contents of /proc/asound/card0/rme96 during the recording-at-44100 phase. It will tell e.g. which input you are using since each input type handles the supported sample rates differently, according to the driver source code.
Last edited:
I solved the sox-related issue with a rebuild of the package. Strange, anyway..
Rüdiger
Did you have the same version of OS, alsa-lib, kernel (i.e. alsa drivers), and sox on both machines? It looked like you had two different versions of sox which changed their default behaviour.
Hi,
lsof returns nothing in this case. MPD releases the resources when not playing back anything.
I have no pulseaudio or the like, it is a gui-less system.
I'm using the coaxial input and output since I have an ADI-2 connected serving as ADC/DAC
Rüdiger
lsof returns nothing in this case. MPD releases the resources when not playing back anything.
Code:
EG-Server ~ # lsof /dev/snd/*
EG-Server ~ #
cat /proc/asound/card0/rme96
RME Digi96/8 PST at 0xfd000000, irq 20 (index #1)
General settings
period size: 8192 bytes
Input settings
input: coaxial (2 channels)
sample rate: 44100 Hz
sample format: 24 bit
Output settings
output signal: normal playback
sample rate: 44100 Hz
sample format: 16 bit
sample clock source: internal
format: IEC958 (consumer)
emphasis: off
non-audio (dolby): off
Analog output settings
monitored ADAT tracks: 1+2
attenuation: 0 dB
volume left: 89
volume right: 89
I have no pulseaudio or the like, it is a gui-less system.
I'm using the coaxial input and output since I have an ADI-2 connected serving as ADC/DAC
Rüdiger
Last edited:
Thanks for very fast response, it is pleasure to co-operate 🙂
So you are capturing SPDIF input. That means the input samplerate is not defined by your card, but by the incoming signal. The SPDIF receiver in RME96 detects the samplerate and the driver reads it - see git.alsa-project.org Git - alsa-kmirror.git/blob - pci/rme96.c
How do you switch the samplerate of ADI-2 output SPDIF you are recording? Perhaps by your card outputing the desired SPDIF signal? What device provided clock signal while you did your testing?
That would explain why you have to output the desired samplerate to ADI-2, the device will adjust SPDIF header of its outgoing SPDIF signal accordingly, and only after that can you record your desired 96000 natively. Makes sense to me 🙂
So you are capturing SPDIF input. That means the input samplerate is not defined by your card, but by the incoming signal. The SPDIF receiver in RME96 detects the samplerate and the driver reads it - see git.alsa-project.org Git - alsa-kmirror.git/blob - pci/rme96.c
How do you switch the samplerate of ADI-2 output SPDIF you are recording? Perhaps by your card outputing the desired SPDIF signal? What device provided clock signal while you did your testing?
That would explain why you have to output the desired samplerate to ADI-2, the device will adjust SPDIF header of its outgoing SPDIF signal accordingly, and only after that can you record your desired 96000 natively. Makes sense to me 🙂
Hey, I'm the one who's to be grateful 😎
the clock source was internal. This is the only way to feed the ADI-2 different sample rates without switching them manually.
The ADI is then set in slave mode. On longer sessions with analog input, I use the ADI-2 clock, it sounds a bit better this way. (at least I feel that way...)
My point is, that both sox and mpd can switch the card to the desired sample rate, but arecord can't or doesn't. And I use sox for recording!
[/CODE]
the clock source was internal. This is the only way to feed the ADI-2 different sample rates without switching them manually.
The ADI is then set in slave mode. On longer sessions with analog input, I use the ADI-2 clock, it sounds a bit better this way. (at least I feel that way...)
My point is, that both sox and mpd can switch the card to the desired sample rate, but arecord can't or doesn't. And I use sox for recording!
Code:
EG-Server musik # ./sox_riaa_alt
sox: SoX v14.3.2
Input File : 'hw:0,0' (alsa)
Channels : 2
Sample Rate : 96000
Precision : 32-bit
Sample Encoding: 32-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Output File : 'hw:0,0' (alsa)
Channels : 2
Sample Rate : 96000
Precision : 32-bit
Sample Encoding: 32-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
sox INFO sox: effects chain: input 96000Hz 2 channels
sox INFO sox: effects chain: biquad 96000Hz 2 channels
sox INFO sox: effects chain: output 96000Hz 2 channels
In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0
Code:
[CODE] cat /proc/asound/card0/rme96
RME Digi96/8 PST at 0xfd000000, irq 20 (index #1)
General settings
period size: 8192 bytes
Input settings
input: coaxial (2 channels)
sample rate: 96000 Hz
sample format: 24 bit
Output settings
output signal: normal playback
sample rate: 96000 Hz
sample format: 24 bit
sample clock source: autosync
format: IEC958 (consumer)
emphasis: off
non-audio (dolby): off
Analog output settings
monitored ADAT tracks: 1+2
attenuation: 0 dB
volume left: 89
volume right: 89
Last edited:
The reason is arecord cannot set any samplerate by itself when recording SPDIF. The rate is defined by the signal itself. There is no clock to be controlled, unlike when running AD conversion from analog input.
Whereas you tell sox and MPD to play back, to actually generate the signal, switching the soundcard clock and through the ADI device to change the incoming SPDIF signal. That is why they seem to work 🙂 Try running the rec command of sox, best with the -V (verbose) parameter. You should get the same result as with arecord, it is the same situation, the sox only capturing SPDIF will not have control of the soundcard clock anymore.
Whereas you tell sox and MPD to play back, to actually generate the signal, switching the soundcard clock and through the ADI device to change the incoming SPDIF signal. That is why they seem to work 🙂 Try running the rec command of sox, best with the -V (verbose) parameter. You should get the same result as with arecord, it is the same situation, the sox only capturing SPDIF will not have control of the soundcard clock anymore.
Try running the rec command of sox, best with the -V (verbose) parameter. You should get the same result as with arecord, it is the same situation, the sox only capturing SPDIF will not have control of the soundcard clock anymore.
Consider this:
Code:
cat /proc/asound/card0/rme96
RME Digi96/8 PST at 0xfd000000, irq 20 (index #1)
General settings
period size: 8192 bytes
Input settings
input: coaxial (2 channels)
sample rate: 44100 Hz
sample format: 24 bit
Output settings
output signal: normal playback
sample rate: 44100 Hz
sample format: 16 bit
sample clock source: internal
format: IEC958 (consumer)
emphasis: off
non-audio (dolby): off
Analog output settings
monitored ADAT tracks: 1+2
attenuation: 0 dB
volume left: 89
volume right: 89
EG-Server musik # sox -b 32 -t alsa hw:0,0 -r 96000 -t alsa hw:0,0 -V --buffer 65536 biquad 0.1170960 -0.0999452 -0.0129345 1.0 -1.866608 0.8670383
sox: SoX v14.3.2
Input File : 'hw:0,0' (alsa)
Channels : 2
Sample Rate : 96000
Precision : 32-bit
Sample Encoding: 32-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Output File : 'hw:0,0' (alsa)
Channels : 2
Sample Rate : 96000
Precision : 32-bit
Sample Encoding: 32-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
sox INFO sox: effects chain: input 96000Hz 2 channels
sox INFO sox: effects chain: biquad 96000Hz 2 channels
sox INFO sox: effects chain: output 96000Hz 2 channels
In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0
cat /proc/asound/card0/rme96
RME Digi96/8 PST at 0xfd000000, irq 20 (index #1)
General settings
period size: 8192 bytes
Input settings
input: coaxial (2 channels)
sample rate: 96000 Hz
sample format: 24 bit
Output settings
output signal: normal playback
sample rate: 96000 Hz
sample format: 24 bit
sample clock source: internal
format: IEC958 (consumer)
emphasis: off
non-audio (dolby): off
Analog output settings
monitored ADAT tracks: 1+2
attenuation: 0 dB
volume left: 89
volume right: 89
Indeed I have to restart sox once to switch the card to 96k (i get xruns at the first time) but then it works the 2nd time. Switching back to 44.1 with mpd is no problem.
With arecord I can restart it a dozen times without the souncard changing the sample rate.
Last edited:
Let me say it again: The difference between arecord and your sox loop is that arecord does no playback, whereas your sox the way you run it does. The playback code of sox changes your RME clock to 96000. This results in the incoming SPDIF stream changing to 96000 and the capturing code can record at 96000. There is no magic involved 🙂
Just run sox in the capture mode, i.e. do not playback, but store to wav.
sox -b 32 -r 96000 -t alsa hw:0,0 recorded.wav
You will experience the exact same behaviour as arecord - sox will not touch the soundcard clock.
It is all about this single concept - when recording SPDIF stream you have no control over the samplerate, your capturing part of the card is slaved to that stream. It is very different to recording analog signals where you can choose at which rate your ADC operates.
And the RME96 driver respects this fact correctly. Look at the function
snd_rme96_capture_hw_params , line git.alsa-project.org Git - alsa-kmirror.git/blob - pci/rme96.c .
IF input type = ANALOG, set rate to the desired rate requested by the recording application in the params structure:
ELSE (i.e. digital inputs) only compare if the requested rate equals the current rate of the incoming stream
And that is the correct way. In Juli@ and other cards with ak411X SPDIF receivers, the driver even wakes up every HZ/10 (i.e. typically 10ms) to check whether the incoming rate has not changed. If it did and capturing is under way, the driver stops capturing and reports an error.
Just run sox in the capture mode, i.e. do not playback, but store to wav.
sox -b 32 -r 96000 -t alsa hw:0,0 recorded.wav
You will experience the exact same behaviour as arecord - sox will not touch the soundcard clock.
It is all about this single concept - when recording SPDIF stream you have no control over the samplerate, your capturing part of the card is slaved to that stream. It is very different to recording analog signals where you can choose at which rate your ADC operates.
And the RME96 driver respects this fact correctly. Look at the function
snd_rme96_capture_hw_params , line git.alsa-project.org Git - alsa-kmirror.git/blob - pci/rme96.c .
IF input type = ANALOG, set rate to the desired rate requested by the recording application in the params structure:
Code:
snd_rme96_capture_analog_setrate(params_rate(params))
ELSE (i.e. digital inputs) only compare if the requested rate equals the current rate of the incoming stream
Code:
rate = snd_rme96_capture_getrate(rme96, &isadat)
if ((int)params_rate(params) != rate) THEN return error
And that is the correct way. In Juli@ and other cards with ak411X SPDIF receivers, the driver even wakes up every HZ/10 (i.e. typically 10ms) to check whether the incoming rate has not changed. If it did and capturing is under way, the driver stops capturing and reports an error.
- Status
- Not open for further replies.
- Home
- Source & Line
- PC Based
- Considering old hardware for an audio player/recorder