Apartment topology
The latest apartment network ended up being
sin: direct torrent VPN to 5Ghz Comca$t
xena: router from wired network to 5Ghz Comca$t
piano: 2.4Ghz router from desks & phone to wired network
5Ghz for the phone is still a dream, since it would eliminate ADB file transfers. While Linux technically supports concurrent AP & STA, it's not practical. The fundamental limit is the AP can't exist if the STA isn't joined.
They have to 1st get connected on the STA, then run iwlist wlan0 channel to sniff out the channel, then start the access point with the hostapd.conf file edited to contain the same channel. The problem is Comca$t can still go down & rejoin on different channels, breaking the access point.
Unfortunately, virtual wlan0 devices behave badly when the 2
frequencies don't match. The Comca$t outages would almost require the
router to reboot.
A hostapd wrapper would have to continuously monitor the station frequency & drop kick it. The problem is there can't be any access point if Comca$t is down. It can't reconfigure wlan0 for the access point frequency while sniffing for the Comca$t frequency.
The best dual mode example has been
https://github.com/idev1/rpihotspot/blob/master/setup-network.sh
It's still only half complete. The 2 Comca$t connections desperately need a script that rejoins Comca$t when it goes down. That's the kind of thing the graphical network managers could do. Restarting hostapd on the other paw is 1 of the things the graphical network managers can't handle & there's no fully baked solution.
It's kind of like the lion kingdom's 1st foray into dialup & the need to make custom scripts for redialing, with "expect" scripts. All the 5Ghz raspberry pi's are now deployed. 1 has a dead ethernet port & the other has a dead power chip. There's a chance 1 of them could be revived with donor parts.
The most likely improvement is the 2.4Ghz raspberry pi being deployed just for the desks & the piano becoming the 5Ghz phone access point. The current desk situation is the lowest cost & a pain. It really only benefits from being free & the coolness of furniture on wifi. The next step up in cost would be buying new sub Ghz radios for the desks so they don't need a router anymore. A new 5Ghz raspberry pi would not be justified.
Then lions would complain about having 4 unused ESP8266's. Perhaps they could be hacked into raw 2.4Ghz receivers. The transmitter has to come up instantly.
----------------------------------------------------------------------------------------------------------
10/19: The raspberry pi situation improved with a repair of that dead eth.
A rough examination spotted a missing ferrite bead, undoubtedly knocked off from driving with it unsecured. The dead board donated its ferrite bead, but it might work with a dead short.
As far as the completely dead board, in the years since, the internet discovered a common problem with the MXL7704. The 3.3V pin gets permanently shorted to ground if it gets wet & jumps to the 5V.
https://repair.wiki/w/Raspberry_Pi_MXL7704
It's definitely end of life & there are no easy replacements. Providing 3V from a daughter board might be the best option. Might have to protect the remaneing boards with hot snot, but it really needs some minimal fuse.
-----------------------------------------------------------------------------------
5Ghz phone conversion
To get the phone on 5Ghz while keeping the desks unchanged, finally attempted to use the TP-LINK wifi dongle to add a 2.4Ghz access point to xena. Problem #1 was building the RTL8192EU driver
https://github.com/lord2y/rtl8192eu-arm-linux-driver
It required matching kernal headers for the ancient kernal, which simply aren't available. They don't archive anything. Got it to update the kernal with apt. Then the git module would compile & install for 5.10 with a few hacks.
Then hostapd & dnsmasq came up without issue.
The dual band monster was born. The 5Ghz & 2GHZ SSIDs must be different or the phone will randomly join the wrong one.
Sadly, with all this configured, 5Ghz uploads to the phone were only 200kbyte/s going to RAM. 5Ghz downloads were much faster, at 5MB/sec. Most disappointing, since data going to the phone should be higher priority.
It was because of very inefficient software. Data to the phone goes to WebServer.getData. It read 1 char at a time into a RAM copy of the entire file, then compared the complete boundary code to end of the RAM copy look for the boundary code.
Data from the phone comes from sendFile. It read 64k at a time.
The 1st problem was it needed to use BufferedInputStream instead of InputStream to get the chars faster. Lions used Java for 25 years without knowing the buffered stream classes optimized reads.
For detecting the boundary code, grok recommended shifting 1 character into a FIFO at a time & comparing the entire array before writing 1 character from the FIFO. That got it to 2 MB/sec, but lions ended up using the days without injury algorithm & shifting 65536 chars at a time into the FIFO. That got it to 8MB/sec, possibly faster than ADB.
Downloads with BufferedOutputStream similary got up to 8MB/sec. They obviously use asynchronous I/O.
Helas, this now got lions pondering all the trouble using tablets & phones for rep counting & camera previews. That was probably also the InputStream parsing. Suspect the mane problem was still 2.4Ghz wifi rather than stream buffering.
---------------------------------------------------------------------------------------------------------
Circling back to Cinelerra, if you count total samples in & total samples out, inside VirtualAConsole::process_buffer, you find all the fast forward time stretching to be fractions of a percent off & causing the audio to lose sync. It's a real problem when watching long form movies.
It's not popping though & it's properly oscillating to compensate for buffer alignment.
The algorithm was last diagrammed thus:
https://growmane.blogspot.com/2025/05/this-low-gravityll-make-you-soft.html
The ratio of the drop_count to dissolve_count determines the playback speed & must be constant. The algorithm was previously not accounting for the fractional parts of the 2 counts, so not getting the right ratio.
It needed to accumulate the remaneders of the 2 counts, constantly applying the integer parts of the remaneders to the 2 counts to get the exact long term ratio. This required the dissolve operations to all apply to the same window so the dissolve buffer could change size between windows.
With that out of the way, there is now a modular TimeStretch class which gives more intelligible results than the timestretch plugin. It might not do as well with very small changes, though.
It was a big weekend between Webphone & Cinelerra.
Comments
Post a Comment