16 Nov
2016
16 Nov
'16
4:17 p.m.
Hi,
I try to get bit-transparent playback/recording of a stereo stream with
a RME 9632 card.
My test setup the card clocked at 48 kHz and the AES input and output
looped.
When I tried to use pure alsa, I recorded 10 channels to get channels 9
and 10 which is the AES input (I wasn't able to find a way to record
only channels 9 and 10). However, I'm not able to play back anything
during the recording. I get the error message "set_params:1361: Unable
to install hw params".
I also tried jack and started jackd this way:
$ jackd -R -d alsa -d hw:DSP -z none -M -H
I was able to play back a square sample and record channels 9 and 10
using jack_rec. However, the result looks like it went though bad AD/DA
conversion: jumpy edges and the linear parts unclean, too.
I'll try to find out if the playback or recording part is the culprit.
However, I'd like to get some comments if bit-transparent
playback/recording can work at all with my setup. If it does, I'd
appreciate to get some hints how to achieve this.
Regards,
Tino
17 Nov
17 Nov
10:31 p.m.
New subject: bit-transparent playback/recoding over AES using an RME 9632 card
On 11/16/2016 04:17 PM, Tino Mettler wrote:
Hi,
I try to get bit-transparent playback/recording of a stereo stream with
a RME 9632 card.
My test setup the card clocked at 48 kHz and the AES input and output
looped.
Which means you connected the digital output to the digital input I guess?
When I tried to use pure alsa, I recorded 10 channels
to get channels 9
and 10 which is the AES input (I wasn't able to find a way to record
only channels 9 and 10). However, I'm not able to play back anything
during the recording. I get the error message "set_params:1361: Unable
to install hw params".
Do you count "channel 9 and 10" one or zero indexed? :)
Here is the channel mapping from the source for reference:
static char channel_map_H9632_ss[HDSP_MAX_CHANNELS] = {
/* ADAT channels */
0, 1, 2, 3, 4, 5, 6, 7,
/* SPDIF */
8, 9,
/* Analog */
10, 11,
/* AO4S-192 and AI4S-192 extension boards */
12, 13, 14, 15,
/* others don't exist */
-1, -1, -1, -1, -1, -1, -1, -1,
-1, -1
};
I also tried jack and started jackd this way:
$ jackd -R -d alsa -d hw:DSP -z none -M -H
I was able to play back a square sample and record channels 9 and 10
using jack_rec. However, the result looks like it went though bad AD/DA
conversion: jumpy edges and the linear parts unclean, too.
Depending on what you "mean" with "the result" this looks perfectly
fine
to me. To be expected of a sampled square wave signal.
How did you generate the signal?
How did you measure/visualize the output?
Keep in mind, that with a limited sample rate, you will always have an
approximated square wave, looking exactly as you described: rippled
linear parts and jumpy edges. This has nothing to do with a loss of
quality in the digital domain.
If you want to check bit transparency, you need to compare the samples
of your digital input and output.
I'll try to find out if the playback or recording part is the culprit.
However, I'd like to get some comments if bit-transparent
playback/recording can work at all with my setup. If it does, I'd
appreciate to get some hints how to achieve this.
I don't see any reason why it would not work if you connect the digital
output to the digital input.
Regards,
Tino
Greetings
Markus
18 Nov
18 Nov
3:59 p.m.
New subject: bit-transparent playback/recoding over AES using an RME 9632 card
On Thu, 2016-11-17 at 22:26 +0100, Markus Seeber wrote:
On 11/16/2016 04:17 PM, Tino Mettler wrote:
Yes.
My test setup the card clocked at 48 kHz and the
AES input and
output
looped.
Which means you connected the digital output to the digital input I
guess? Do you count "channel 9 and 10" one or zero
indexed? :)
Here is the channel mapping from the source for reference:
static char channel_map_H9632_ss[HDSP_MAX_CHANNELS] = {
/* ADAT channels */
0, 1, 2, 3, 4, 5, 6, 7,
/* SPDIF */
8, 9,
One indexed.
Depending on what you "mean" with "the
result" this looks perfectly
fine
to me. To be expected of a sampled square wave signal.
How did you generate the signal?
How did you measure/visualize the output?
Maybe I was a bit unclear. I generated a square sample and saved it
into a .wav file, as 48 kHz/16 bit/stereo. I expected to see the same
PCM data when recording it.
If you want to check bit transparency, you need to
compare the
samples
of your digital input and output.
I thought I did exactly that, or do you mean I need to compare the
physical signal on the cable?
I don't see any reason why it would not work if
you connect the
digital
output to the digital input.
Actually, a colleague of mine did exactly that in Windows, using
another RME card.
Here are example screenshots of the original and the recording:
https://tikei.de/playback.png
https://tikei.de/recording.png
Regards,
Tino
6:31 p.m.
New subject: bit-transparent playback/recoding over AES using an RME 9632 card
On Fri, November 18, 2016 8:59 am, Tino Mettler wrote:
Actually, a colleague of mine did exactly that in
Windows, using
another RME card.
Here are example screenshots of the original and the recording:
https://tikei.de/playback.png
https://tikei.de/recording.png
That looks correct. Do you have pictures of your result?
--
Chris Caudle
7:31 p.m.
New subject: bit-transparent playback/recoding over AES using an RME 9632 card
On 11/18/2016 06:30 PM, Chris Caudle wrote:
On Fri, November 18, 2016 8:59 am, Tino Mettler
wrote:
And if you use audacity, could you zoom in far enough so the discrete
sample values can be seen? Just generate a 440Hz square wave, that
should be fine.
Actually, a colleague of mine did exactly that in
Windows, using
another RME card.
Here are example screenshots of the original and the recording:
https://tikei.de/playback.png
https://tikei.de/recording.png
That looks correct. Do you have pictures of your
result?
8:17 p.m.
New subject: bit-transparent playback/recoding over AES using an RME 9632 card
On 11/18/2016 07:26 PM, Markus Seeber wrote:
On 11/18/2016 06:30 PM, Chris Caudle wrote:
Oh and I just noticed, that care has to be taken when importing and
exporting audio from and into audacity.
If you generate a track at 48 KHz sample rate, make sure you global
settings are also set to 48 KHz or else your import/export gets screwed
and material gets resampled without warning, resulting in exactly the
pattern you have described.
I just stumbled over this, hell this is annoying.
So basically:
1. Edit -> Preferences -> Quality and set default sample rate and format
to what you need, probably 32 bit float 48KHz
2. Create a mono audio track
3. click on the little drop down menu on the top left of the track strip
and make sure that the correct rate and format is set.
4. generate the square wave
5. export the wav and make sure again, to select 32bit float pcm
6. import the exported file again, if it looks exactly the same, it was
done right.
Then with the exported file, do your tests again and let's see if it
wasn't just Audacity screwing up the whole measurement.
On Fri, November 18, 2016 8:59 am, Tino Mettler
wrote:
And if you use audacity, could you zoom in far enough so the discrete
sample values can be seen? Just generate a 440Hz square wave, that
should be fine.
Actually, a colleague of mine did exactly that in
Windows, using
another RME card.
Here are example screenshots of the original and the recording:
https://tikei.de/playback.png
https://tikei.de/recording.png
That looks correct. Do you have pictures of your
result?
21 Nov
21 Nov
9:43 a.m.
New subject: bit-transparent playback/recoding over AES using an RME 9632 card
On Fri, 2016-11-18 at 11:30 -0600, Chris Caudle wrote:
On Fri, November 18, 2016 8:59 am, Tino Mettler
wrote:
Hi,
the recording.png is the result from recording the playback from
playback.png. It should be identical for bit-transparency.
Regards,
Tino
Actually, a colleague of mine did exactly that in
Windows, using
another RME card.
Here are example screenshots of the original and the recording:
https://tikei.de/playback.png
https://tikei.de/recording.png
That looks correct. Do you have pictures of your result? 
12:33 p.m.
New subject: bit-transparent playback/recoding over AES using an RME 9632 card
On Monday 21 November 2016, Tino Mettler wrote:
On Fri, 2016-11-18 at 11:30 -0600, Chris Caudle
wrote:
Be aware that a rectangular wave has infinite frequency components in
its edges. In any real physical system you have to lowpass this
signal (either the reconstruction and / or the anti-aliasing filter).
After filtering into the frequency range of interest (smaller than
half sampling frequency) the wave looks like what you show in
recording.png.
This is in each case true for a analog out- and input. I assume that a
digital connection as well has to filter the signal as well to stay
in the allowed frequency band according to your sample rate. Others
might skim in with more knowledge on the digital side.
Gerhard
PS: apply a lowpass filter in Audacity to your playback signal and you
will see the effect.
On Fri, November 18, 2016 8:59 am, Tino Mettler
wrote:
Hi,
the recording.png is the result from recording the playback from
playback.png. It should be identical for bit-transparency.
Actually, a colleague of mine did exactly that in
Windows,
using another RME card.
Here are example screenshots of the original and the recording:
https://tikei.de/playback.png
https://tikei.de/recording.png
That looks correct. Do you have pictures of your result?
12:52 p.m.
New subject: bit-transparent playback/recoding over AES using an RME 9632 card
On Mon, 2016-11-21 at 12:33 +0100, Gerhard Zintel wrote:
I assume that a
digital connection as well has to filter the signal as well to stay
in the allowed frequency band according to your sample rate.
Hi, I tried to avoid that, by using a 48 kHz PCM sample for playback,
transmitting it over AES/EBU as PCM data with the card clocked at 48
kHz, and recording at 48 kHz from the same clock.
Regards,
Tino
1:38 p.m.
New subject: bit-transparent playback/recoding over AES using an RME 9632 card
On Monday 21 November 2016, Tino Mettler wrote:
On Mon, 2016-11-21 at 12:33 +0100, Gerhard Zintel
wrote:
yes, but be aware
that the sample shown in playback.png has much
higher frequency components than 48 kHz.
G
I assume that a
digital connection as well has to filter the signal as well to
stay in the allowed frequency band according to your sample
rate.
Hi, I tried to avoid that, by using a 48 kHz PCM sample for
playback, transmitting it over AES/EBU as PCM data with the card
clocked at 48 kHz, and recording at 48 kHz from the same clock.
4:19 p.m.
New subject: bit-transparent playback/recoding over AES using an RME 9632 card
On Mon, 2016-11-21 at 12:52 +0100, Tino Mettler wrote:
On Mon, 2016-11-21 at 12:33 +0100, Gerhard Zintel
wrote:
Problem solved. It looks like one should also care that the playback
tool can play out without messing around with the input. I now tried
plain mplayer and it works as expected.
Sorry for the noise. (absolutely no pun intended :-)
Regards,
Tino
I assume that a
digital connection as well has to filter the signal as well to
stay
in the allowed frequency band according to your sample rate.
Hi, I tried to avoid that, by using a 48 kHz PCM sample for playback,
transmitting it over AES/EBU as PCM data with the card clocked at 48
kHz, and recording at 48 kHz from the same clock.
4:44 p.m.
New subject: bit-transparent playback/recoding over AES using an RME 9632 card
On 11/21/2016 04:19 PM, Tino Mettler wrote:
On Mon, 2016-11-21 at 12:52 +0100, Tino Mettler
wrote:
No problem, it's nice to have some "brain jogging" in signal processing
from time to time. :)
Greetings
Markus
On Mon, 2016-11-21 at 12:33 +0100, Gerhard Zintel
wrote:
Problem solved. It looks like
one should also care that the playback
tool can play out without messing around with the input. I now tried
plain mplayer and it works as expected.
Sorry for the noise. (absolutely no pun intended :-)
Regards,
Tino
I assume that a
digital connection as well has to filter the signal as well to
stay
in the allowed frequency band according to your sample rate.
Hi, I tried to avoid that, by using a 48 kHz PCM sample for playback,
transmitting it over AES/EBU as PCM data with the card clocked at 48
kHz, and recording at 48 kHz from the same clock.
4:42 p.m.
New subject: bit-transparent playback/recoding over AES using an RME 9632 card
On 11/21/2016 12:33 PM, Gerhard Zintel wrote:
On Monday 21 November 2016, Tino Mettler wrote:
Additional filtering in this
case would only be necessary when
converting the sample rate between the audio file and the target output
sample rate. If both are the same, we should be able to get "precise"
output. (neglecting eventual numerical issues from converting floating
point to integer samples and vice versa, which are not that relevant in
the square wave case anyway)
On Fri, 2016-11-18 at 11:30 -0600, Chris Caudle
wrote:
Be aware that a rectangular wave has infinite frequency components in
its edges. In any real physical system you have to lowpass this
signal (either the reconstruction and / or the anti-aliasing filter).
After filtering into the frequency range of interest (smaller than
half sampling frequency) the wave looks like what you show in
recording.png.
This is in each case true for a analog out- and input. I assume that a
digital connection as well has to filter the signal as well to stay
in the allowed frequency band according to your sample rate. Others
might skim in with more knowledge on the digital side. On Fri, November 18, 2016 8:59 am, Tino Mettler
wrote:
Hi,
the recording.png is the result from recording the playback from
playback.png. It should be identical for bit-transparency.
Actually, a colleague of mine did exactly that in
Windows,
using another RME card.
Here are example screenshots of the original and the recording:
https://tikei.de/playback.png
https://tikei.de/recording.png
That looks correct. Do you have pictures of your
result?
2925
days inactive
2930
days old
linux-audio-user@lists.linuxaudio.org
12 comments
4 participants
participants (4)
-
Chris Caudle -
Gerhard Zintel -
Markus Seeber -
Tino Mettler