[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Is there a reason why this wouldn't shift the si

From: Jonathan Coveney
Subject: Re: [Discuss-gnuradio] Is there a reason why this wouldn't shift the signal that is demodulated?
Date: Sun, 9 Aug 2009 20:41:33 -0400

Who knows how such things got changed, but that would make complete sense, and it did indeed fix that problem.

As a nerdy question, are there any particularly amenable ways to compress the sample files? 2 seconds of 4MS/s is like 130MB/s. The normal mac compression gave me about 25% of the size... which is good, but you never know.

2009/8/9 Michael Dickens <address@hidden>
On Aug 9, 2009, at 5:03 PM, Jonathan Coveney wrote:

I know you say not to use a throttle, but for some reason it absolutely does not work without one. Any idea why that would be? It sounds very distorted and sped up, and then I get a bunch of xO errors. With throttling it works perfectly.

"oX" means that the data is coming in too fast for the sink to handle so data is being dropped.  I think this notation is non-standard for audio sinks, but there is it.

The instantiation of an audio_sink is typically:

audio_sink (int sample_rate,
           const std::string device_name,
           bool do_block)

and by default "do_block" is supposed to be true ... but for some reason either it's false in your case (instantiated that way?), or maybe something is broken in the OSX audio sink.

In your Python script, try instantiating the audio_sink with the sample rate, the device name (I think OSX uses numbers, e.g., "1", "2", etc.), and true for blocking.  If that doesn't work, then something is broken somewhere. - MLD

reply via email to

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