it seems, pyaudio isnt terminated correctly. running it within a subprocess which will be closed after execution, pyaudio seems to be terminated and not causing a problem anymore on raspberry pi. Yay
...and a lot of different changes. Also deactivated single mode transmission. This needs to be optimised another day...Time is the missing ressource...
changed protocol so IRS is now the speed-level master / send ptt state via network / introduced no rig mode / disable scatter and waterfall in gui and tnc/ increased network chunk size / ...
..and some other changes to the gui so its compatible again with the latest socket commands. The rx buffer has now a unique id, and new structure. Also all messages and files will be saved to the same buffer. All commands which will be sent to the tnc or dameon are now written in lowercase
an attempt with a locking state for the mod_out queue so we can process audio only, if we finished filling our mod_out queue. Possibly this solves the problems #99#127
updated the modem and codec2 integration. However, this is the old modem. Maybe we need to stay at this point. Lets see how this version performs...hmpf...
data handler is now ready for chat messages. I updated the data frame with an additional information -datatype- so we can determine if we received a file or a message. Each datatype will be saved into an own buffer. The gui has been updated as well, so we can forward data directly to a future chat module...
first attempt with info toasts which seems to work fine. Next step will be adding more detailed information to them like a progress bar and specific closing
first attempt with stopping a transmission after the processing the current burst. Logging is a little bit ugly at this point, because it looks like a frame got lost. However, the transmission stops. CLI output is only visible for people interested in debugging...
