Audio sink does not throttle sample flow

Hi all,

I recently wrote a block for decoding DRM AAC streams. For testing I put
together a small flow graph consisting of a wav source, encoder block,
decoder block, (rational) resampler and an audio sink (an image of the
flow graph is attached).

When I now run this flow graph, the audio is correctly decoded, but the
output is not throttled to 44.1 kHz as it should be. It seems to be
running at full speed. I also connected a resampler and an audio sink
directly to the wav source and there the output is correct.

I use default values for the audio sink (alsa, 44.1 kHz), GNU Radio
3.5.1 and xubuntu 11.10.

Any hints why this is happening and how to solve this?

Best regards,
Felix W.

On Tue, Aug 7, 2012 at 6:22 AM, Felix W.
[email protected] wrote:

the wav source and there the output is correct.

I use default values for the audio sink (alsa, 44.1 kHz), GNU Radio 3.5.1
and xubuntu 11.10.

Any hints why this is happening and how to solve this?

Best regards,
Felix W.

Felix,

I know that the audio sink will throttle the flow graph. What evidence
do you have that it’s not or that it’s running at full speed? Is it
the sound coming from the audio? My first guess is that there’s a
misunderstanding somewhere of the actual sample rate. You’re
resampling by almost 2x, which means you expect the signal coming from
the decoder to be 44.1e3/2. Is that right?

Tom

Am 12.08.2012 19:19, schrieb Tom R.:

output is not throttled to 44.1 kHz as it should be. It seems to be running
Felix,

I know that the audio sink will throttle the flow graph. What evidence
do you have that it’s not or that it’s running at full speed? Is it
the sound coming from the audio? My first guess is that there’s a
misunderstanding somewhere of the actual sample rate. You’re
resampling by almost 2x, which means you expect the signal coming from
the decoder to be 44.1e3/2. Is that right?

Tom

Hi Tom,

thanks for your reply.

My first evidence was in fact the sound coming from the audio that is
running at a very high speed. However, the pitch seems to be normal. The
flow graph is set to “run to completion” and processes a 3 min wav-file
in about 15 sec.

The signal coming from the decoder has a sample rate of 24 kHz. I
verified that by writing the decoder output into a file and using aplay
for playback with -r 24000. At this point, the sound is still normal.

The next steps are in detail:

  • Type conversion short->float
  • multiply const (1/32768) for range adjustment
  • rational resampler( interp: 441, decim: 240)
  • audio sink (44.1kHz)

Did I configure the resampler correctly? I left taps blank and
fractional bandwidth at 0.

I also attached a file sink to the output of the resampler and tried to
play it with aplay using -r 44100. It shows the same behaviour like the
audio sink (normal pitch, very fast playback).

Best regards,
Felix

On Mon, Aug 13, 2012 at 5:05 AM, Felix W.
[email protected] wrote:

flow

misunderstanding somewhere of the actual sample rate. You’re
My first evidence was in fact the sound coming from the audio that is

  • multiply const (1/32768) for range adjustment
    Best regards,
    Felix

Felix,

That looks like you’re doing everything correctly. I wonder if it’s an
issue with the sound card, seeing as you’re getting the same behavior
with aplay. Can you set the output device? If you can use pulseaudio,
set the device string to ‘pulse’ and see what that does. Otherwise,
try ‘plughw:0,0’. They might handle the sampling rate settings better.

Tom

On Mon, Aug 13, 2012 at 12:25 PM, Felix W.
[email protected] wrote:

output is not throttled to 44.1 kHz as it should be. It seems to be

the decoder to be 44.1e3/2. Is that right?
flow graph is set to “run to completion” and processes a 3 min wav-file

  • Type conversion short->float
    sink (normal pitch, very fast playback).
    try ‘plughw:0,0’. They might handle the sampling rate settings better.

While I was trying the different setups, I noticed that the file sizes
of my two file sink outputs are not as expected. The decoder output in
my special case is 8.7 MB while the resampler output is no more than 1.1
MB. I would have expected a size of 8.7 MB * resampling rate, about 15 MB.

To me, it looks like I’m losing lots of samples (about 7 out of 8) in
the rational resampler block.

Felix

Sorry, Felix, lost track of things last week. Are you still having
issues or have you solved it?

Since you’re seeing different files sizes, yes, something is going
wrong with you’re resampling. Can you try to plug in the pfb_arbitrary
resampler? You can use the one in blks2 (or
filter.pfb.arb_resampler_xxf if you are working on a branch with
gr-filter already) with which you can just tell it the resampling rate
you want (as a float) and it will create a filter for you that passes
the entire spectrum of the input signal.

Tom

Am 13.08.2012 13:33, schrieb Tom R.:

decoder block, (rational) resampler and an audio sink (an image of the
and xubuntu 11.10.
misunderstanding somewhere of the actual sample rate. You’re
running at a very high speed. However, the pitch seems to be normal. The

  • rational resampler( interp: 441, decim: 240)
    Felix
    Felix,

That looks like you’re doing everything correctly. I wonder if it’s an
issue with the sound card, seeing as you’re getting the same behavior
with aplay. Can you set the output device? If you can use pulseaudio,
set the device string to ‘pulse’ and see what that does. Otherwise,
try ‘plughw:0,0’. They might handle the sampling rate settings better.

Tom
Hi Tom,

I don’t think that it’s a sound card issue as I successfully used the
audio sink before. Nevertheless, I tried pulse and plughw:0,0 to be
sure. Results are exactly the same. I also attached an audio sink
directly to my wav file source at the beginning of the flow graph and
this one is working properly.

While I was trying the different setups, I noticed that the file sizes
of my two file sink outputs are not as expected. The decoder output in
my special case is 8.7 MB while the resampler output is no more than 1.1
MB. I would have expected a size of 8.7 MB * resampling rate, about 15
MB.

To me, it looks like I’m losing lots of samples (about 7 out of 8) in
the rational resampler block.

Felix

Am 22.08.2012 00:09, schrieb Tom R.:

at full speed. I also connected a resampler and an audio sink directly
Felix W.

The signal coming from the decoder has a sample rate of 24 kHz. I

Felix,
I don’t think that it’s a sound card issue as I successfully used the
To me, it looks like I’m losing lots of samples (about 7 out of 8) in
filter.pfb.arb_resampler_xxf if you are working on a branch with
gr-filter already) with which you can just tell it the resampling rate
you want (as a float) and it will create a filter for you that passes
the entire spectrum of the input signal.

Tom

Hi,

Unfortunately, the results stay the same with the pfb_arbitrary
resampler from blks2. I also attached a pfb resampler and an audio sink
to the wav source at the beginning of my flowgraph and there it works.
Sound output is as expected.

After some experimenting and attaching file sinks to virtually every
block in the flow graph I noticed that the data already gets corrupted
in the short to float (!) block directly after the audio decoder. Sorry
for misleading you at first! I do not really expect that there’s a bug
in the type conversion, but maybe someone has an idea what I could have
done wrong. Again: The decoder output can be played back with aplay
without problems.

As it’s getting more and more confusing and complicated, I pushed a
folder “audio_bug” to my github repo (gnuradio_drm/misc/audio_bug) [1]
containing a bug description, some observations and flow graphs to
reproduce the strange behavior for those who are interested.

Best regards,
Felix

[1] git://github.com/fewu/gnuradio_drm.git

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs