Re: [Discuss-gnuradio] WavFile_Sink Issues: slowed down sound - multiplied playing time

[Andrew Davis]

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.

Andrew

On Sat, Aug 31, 2013 at 10:18 AM, Luke Berndt <address@hidden> wrote:

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:

https://soundcloud.com/hackrfsounds/only-recieved-frames

And here is the wav file where the vocoder block always returns the requested number of samples even if nothing was output:

https://soundcloud.com/hackrfsounds/moto-smartnet-recording

My GRC file and the DSD block is here:

https://github.com/robotastic/gr-dsd

If you change /lib/dsd_block_ff.cc on line 365 & 366 you can change how the number of outputted samples is determined.

I have the C++ program the uses this all here: 

https://github.com/robotastic/sdr  under the smartnet directory

 - Luke

On Aug 30, 2013, at 8:53 PM, Andrew Davis <address@hidden> wrote:

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?

Andrew

On Fri, Aug 30, 2013 at 8:23 PM, Luke Berndt <address@hidden> wrote:

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.

Any other tips would be great!

 - Luke

On Aug 30, 2013, at 5:03 PM, Andrew Davis <address@hidden> wrote:

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.

Andrew

On Fri, Aug 30, 2013 at 10:53 AM, Luke Berndt <address@hidden> wrote:

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.

Any idea what is going on or what I can try?

Here is a sample of the output: https://soundcloud.com/hackrfsounds/moto-smartnet-recording

Thanks!

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio