[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Audio sink does not throttle sample flow

From: Felix Wunsch
Subject: Re: [Discuss-gnuradio] Audio sink does not throttle sample flow
Date: Thu, 23 Aug 2012 16:54:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0

Am 22.08.2012 00:09, schrieb Tom Rondeau:
On Mon, Aug 13, 2012 at 12:25 PM, Felix Wunsch
<address@hidden> wrote:
Am 13.08.2012 13:33, schrieb Tom Rondeau:
On Mon, Aug 13, 2012 at 5:05 AM, Felix Wunsch
<address@hidden> wrote:
Am 12.08.2012 19:19, schrieb Tom Rondeau:

On Tue, Aug 7, 2012 at 6:22 AM, Felix Wunsch
<address@hidden> wrote:
Hi all,

I recently wrote a block for decoding DRM AAC streams. For testing I
together a small flow graph consisting of a wav source, encoder block,
decoder block, (rational) resampler and an audio sink (an image of the
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
at full speed. I also connected a resampler and an audio sink directly
the wav source and there the output is correct.

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

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

Best regards,
Felix Wunsch

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?


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
about 15 sec.

The signal coming from the decoder has a sample rate of 24 kHz. I
that by writing the decoder output into a file and using aplay for
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
it with aplay using -r 44100. It shows the same behaviour like the audio
sink (normal pitch, very fast playback).

Best regards,

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.

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.


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.



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,

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]