[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: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Audio sink does not throttle sample flow
Date: Tue, 21 Aug 2012 18:09:23 -0400

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

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.


reply via email to

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