discuss-gnuradio
[Top][All Lists]
Advanced

[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: Mon, 13 Aug 2012 18:25:49 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0


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 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 Wunsch
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
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








reply via email to

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