f4exb / sdrangel

SDR Rx/Tx software for Airspy, Airspy HF+, BladeRF, HackRF, LimeSDR, PlutoSDR, RTL-SDR, SDRplay and FunCube
GNU General Public License v3.0
2.91k stars 441 forks source link

View AM/FM demod output (i.e. audio) in Channel Analyzer #695

Closed srcejon closed 3 years ago

srcejon commented 3 years ago

Is it possible to view the output of the AM & FM demodulators (i.e. demodulated audio) in the Channel Analyzer? If not, I think it would be quite a useful feature to add. Not only for viewing audio, but for analysing non-audio data that uses AM/FM modulation.

I guess it could possibly be achieved by having an audio device source (as per #496). This would be useful so that you could analyse audio from any source, but in this case, would (on Windows at least) require a virtual audio pipe, so an internal path might be preferable.

f4exb commented 3 years ago

I think #496 is unrelated. What you are asking for is watching the demodulated audio in a scope/spectrum combo like the channel analyzer. This is different from having an audio source as a direct I/Q modulator.

I don't think it is desirable to have it as a permanent feature of AM and NFM demodulators that should be kept lightweight I would rather see it as a plugin feature with stream connection.

kasper93 commented 3 years ago

I would rather see it as a plugin feature with stream connection.

Plugins with stream connection could be nice, we could add processing after demodulation like denoising in separate connectable modules.

f4exb commented 3 years ago

Well denoising deserves to be an integral part of the plugin as individual audio post-processing. But more generally yes this could be useful when the data produced by a demodulator (audio, digital symbols, ...) may be processed in one or in another way to produce a secondary output that has a particular functional meaning. The modem concept is a good illustration where some flow of data may be received or transmitted in a particular modulation. Spectrum output can use the same mechanism and this would be necessary to implement the "super" scanner I am thinking of and that already exists as en external process in the v5 branch.

I am also thinking of transponders and repeaters as feature plugins where piping audio is a requirement.

For what concerns this issue I think that we could have a scope feature plugin connectable to the output of some plugins firstly those producing audio.

For the implementation to be flexible and generic enough I am thinking of creating a static object that would be a collection of data "pipes" i.e. byte FIFOs with a producer and a consumer and a process of garbage collection for the pipes that have lost their endpoints. Garbage collection here avoid a complex process of actively deleting the pipe when one endpoint is deleted at the expense of the producer sending its data to the void for some time but I think this is minor and depends on how often the garbage collection is run. Consumers and producers just subscribe and unsubscribe.

Food for thought ...

f4exb commented 3 years ago

Implemented in v6.4.0

srcejon commented 3 years ago

Great, thanks!