So I clearly have a sample rate mis-match. I am trying to record the
audio from the gr-dsd block. I don’t seem to have an issue doing it
using GRC. However when I try doing using C++ the audio sounds extra
slow and choppy and the playing time is much longer than I was actually
recording for. I gr-dsd block is supposed to output audio at 8khz. I
have the wavfile_sink set at 8000 for the samples per sec parameter. I
use the same setting in GRC and it works fine. I have also tried passing
this through a resampler to get the audio rate up to 44.1khz and I still
have the same problem. If I use an audio_sink set to a sample rate of
44100 instead, I am able to listen to the audio with no problem.
I’m not sure exactly what you are doing, but some sound cards don’t
support
very many rates, windows always re-samples to some rate supported by the
card, in linux you get more direct access to sound hardware and so you
can
send it rates it may not like, you could add a re-sampler/sound manager
like pulse to handle all this for you, worked for me with similar
issues.
Thanks Andrew! - I am actually able to play the sound fine through sound
card using the audio_sink block. It was is when I try recording it to a
.wav file using the wavfile_sink block that the sounds becomes
distorted. I have tired using a resampler and also tried a variety of
different sample rate on the wavfile_sink, but none of them sounded
normal.
gr-dsd is a vocoder block and its decoding is sort of bursty. Sometimes
it seems to only take 4 input packets to equal 1 output, others it is 8
or 11. Any wise, I am wondering I am getting some form of under run. I
am not getting ‘aUaU’ on the screen. Sometimes the sound from audio sink
initially sound garbled but then becomes normal, so I wonder if it is an
issue of needing to buffer up. I have tried adding in a Forecast, but it
didn’t help.
I’m not sure about dsd but becouse of the ratio of symbol rate to sample
rate, some digital decoders will take a variable number of inputs per
output, this could without a sizable buffer under-run your sound card,
some
sound servers handle these gaps in the sample stream for you.
Also have you tried just playing the .wav’s in a music player? I have
had
issues with the wavfile_sink messing up the format. Also check that you
are
feeding the wavfile_sink in the format, could you just post your .grc
file
here?
That all sounds about right, I’ve run into problems like that before,
the
example blocks all end by just return the number of output samples
requested, so some projects just do this too when they shouldn’t.
Also the empty blocks idea sounds possible too. With a vocoder sometimes
there may not be enough data to fill a packet every time one is needed
for
transmitting, the modulator may need more packets than can be filled and
so
null packets are inserted. I’ve been doing a bit of work on the gnuradio
ATSC decoder, and I’ve found that about 10-20% of packets are just null
packets, the compression is TOO good and there is not enough data to be
send out at a given instant. The nice thing is the MPEG-TS packets come
with a time reference so you can just insert nulls or drop packets when
you
need to, but i’m not sure if this is the case with the encoding used
with
dsd.
I think I may have figured it out. It has to do with how the signal
processing block that goes around the vocoder was written. The
general_work function for gr_block classes takes in a requested number
of outputs and also returns back how many output items were produced.
The way it was written was that it would also report back the desired
number of outputs were produced even if they were not. This worked fine
for the audio_sink. I had no issues like to the audio through my sound
card / sound server. However with the wav file recorder, it lead to the
slowed down sounds and the actual playing time of the wav file being
many times longer than it should have been.
When I switched the number of outputted items return by general_work to
be the actual number of samples the were processed and ready to be
outputted, the wav file sink started to work. The audio quality of the
recorded wav file is still a little worse than the sound from sound
quality. I think the reason this works is because the audio sink is
“clocked” by the sound card and it only requests more samples once the
buffer for the sound card is empty. On the other hand, I don’t think the
wav file sink is really rate limited, it seems to request more samples
from the vocoder at a much higher rate. When the block lies and just
keeps giving it empty samples whenever the wav file sink asks, the play
time gets inflated and the actual audio bits get watered down with these
fake samples. However, the weird thing is that the audio from the sound
card now sounds weird when the vocoder only gives out samples when there
is actual data. I think, this is because when there is actual data
coming in there should be some empty blocks in between to reconstitute
things.
Is this just crazy talk or does it sound right?
Here is the wav file were it is using only the actual samples produced
and it is intelligible:
And here is the wav file where the vocoder block always returns the
requested number of samples even if nothing was output:
My GRC file and the DSD block is here:
If you change /lib/dsd_block_ff.cc on line 365 & 366 you can change how
the number of outputted samples is determined.