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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
