search

th0ma5w / rtl_fm_python

An API and web application to interact with a running instance of RTL_FM
GNU General Public License v2.0
135 stars 29 forks source link

Inconsistent endianess of sound output #10

Open Tookmund opened 5 years ago

Tookmund commented 5 years ago

When I attempt to use the start_web.sh I can only hear static. If I change it to use thread instead I can hear output:

./rtl_fm_python_thread.py -M wbfm -f 101.1M - |aplay -r 32000 -f S16_LE -t raw -c 1

It also works fine with rtl_fm:

rtl_fm -M wbfm -f 101.1M - |aplay -r 32000 -f S16_LE -t raw -c 1

However, start_web.sh outputs only loud static

th0ma5w commented 5 years ago

Had another user email me with endianess issues on a Pi. Is this a Pi? You could try setting aplay to -f S16_BE and see if that works. I also suspect some dongles may switch the endianess, but something to try at least. If this doesn't work we can try some other things maybe?

Tookmund commented 5 years ago

Not a Pi but a

Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz

However, switching to big endian worked, oddly enough. Any idea why thread is using little endian and web is using big endian?

th0ma5w commented 5 years ago

So yeah no, I'm not sure. I'm glad it worked out. Some other theories are perhaps some dongles are sending bytes BE, librtlsdr is somehow doing that, or some other aspect of the software like something in the Linux kernel or libusb or something. Did your hardware always behave this way? Do you have another stick to swap and try? If not that is cool. I'm glad it is working!

Tookmund commented 5 years ago

I don't have another stick to test unfortunately. I'll try some other computers and report back. I have an Ezcap DVB-T if that helps.

https://www.aliexpress.com/item/EZCAP-DVB-T-FM-DAB-USB-2-0-HDTV-Stick-for-Watching-and-Recording-HDTV-Digital/1803468866.html

Tookmund commented 5 years ago

Ok did more testing and found an odd correlation If I use a virtualenv I get big endian but if I use the system python I get little endian IDK why this would change the endianess

Tookmund commented 5 years ago

This only happens with rtl_fm_python_web, thread is not affected To use a virtualenv I have to change the shebang to #!/usr/bin/env python

Tookmund commented 5 years ago

System python uses older versions of flask and its dependencies but idk how that would affect endianess.

th0ma5w commented 5 years ago

Just so weird. I mean, so, I'm using ctypes so really all the stdin and stdout should be handled by the operation of the C code... which is just a slightly modified version of rtl_fm.c ... You're right that there are all kinds of other code being loaded into memory with the web version, but the thread named one should just be mostly Python and the standard lib. Anyway, I'm not sure how much control I'd have really...

I feel like when / if I find (or someone finds) what is going on, it will seem obvious in hindsight but as of now I either have too many uninformed ideas or really none at all.

Perhaps something about flask, or its dependencies, are turning on some kind of memory writing mode ...

Something to try would be to move the flask imports from the web script to just after line 25 and the make_rtl_fm_thread command. The thinking being flask sets something it needs globally, but if we have the rtl stuff going before that then maybe it'll stop affecting us.

Anyway...... So weird.

Tookmund commented 5 years ago

Moving flask imports after make_rtl_fm_thread(block=False) did not fix the problem

Idk if this'll find anything but I'm going to go look at changelogs for these and see if theres anything relevant:

Dependency virtualenv (Broken) System (Working)
Flask 1.0.3 1.0.2
itsdangerous 1.1.0 0.24
Jinja2 2.10.1 2.10
MarkupSafe 1.1.1 1.1.0
Werkzeug 0.15.4 0.14.1
Tookmund commented 5 years ago

Ok I've narrowed it down with some testing in a virtual environment and I can confirm that it is flask 1.0.3 that breaks this somehow. If I install 1.0.2 it works fine, but switches to big endian with 1.0.3

I tested all the other changed dependencies but only flask 1.0.3 switched the endianess

th0ma5w commented 5 years ago

It is surprising to me that the changing of the import order didn't seem to help, but maybe some other re-ordering of calls could help.

I received confirmation from another user that Flask 1.0.3 is the problem, so kudos greatly for finding that. Are you also saying you isolated out the dependencies as well? I guess what I'd have to do is compare a diff of everything between to virtualenvs and see if anything pops out.

I scoured the Flask commits as best I could and nothing seemed related. In my mind it has to be something that ultimately gets compiled to native code and is forcing big endianness, if available, in order to do some kind of speed up or something I'm not sure what other advantage forcing another endianness if not the native one other than code re-use (although you'd have to program both I'd think still to be compatible) or there must be some kind of optimization... That points to the templating libraries maybe as I believe they have some nice speed ups possibly like this?

Anyway... Since we know of a fix and hopefully others having this issue will see this thread, it perhaps isn't critical, but it sure is a curious thing.