cop,48 produces choppy and broken telemetry #481
Comments
|
Observed as early as July 2024 from AllStarLink Community forums: Am I the only seeing ‘cop 48’ weirdness in ASL3? |
|
The July 2024 community reference suggests a regression between ASL2 and ASL3 |
|
Moving to app_rpt |
|
This seems to make "sense" - when we trigger the code generating the error message: app_rpt/channels/chan_simpleusb.c Lines 2072 to 2076 in bbb6a19 The function exits without processing the usb write logic (which is after the read) app_rpt/channels/chan_simpleusb.c Lines 2092 to 2099 in bbb6a19 Skipping the write buffer for too long will cause it to overflow, essentially dropping tones (or making weird sounds). I was looking at this same code while researching the "scratchy audio" problem in the newer kernels >.29, and thought it was interesting that we coupled reading and writing. I suspect the difficulty we have keeping the write buffer full is caused by the coupling here. No solution yet.... only some ideas :) |
|
I think it would be helpful to listen to the audio that is being set to the channel driver. That will point us in the correct direction. Assuming you are using simpleusb. Use this command to capture the TX audio. Send the cop,48 command. When it finishes, issue this command. The above will give you the following file. This is a raw wave file with no header. Please post it to this issue. |
|
I can also confirm similar results with COP 48 - debug file attached with thread blocking complaints. Active threads from |
Description
cop,48 in app_rpt does not produce consistent audio fidelity with tone playback, either with single tones, mixed tones/tone sequences, or pre-programmed tones, i.e. dual-tone multi-frequency (DTMF) sequences. The bug seems to manifest as though it has a buffering issue; it may, for example, produce one or two DTMF digits from a named sequence and not produce the rest, or skip through sequences, or hold on and play some tone sequences endlessly.
Reproduction
Two examples that 'stress' cop,48 behavior:
node504381*CLI> rpt cmd 504381 cop 48 !830+827/450,!0/250,!659+656/450,!0/250,!739+736/450,!0/250,!493+490/450,!0/750,!493+490/450,!0/250,!739+736/450,!0/250,!830+827/45 0,!0/250,!659+656/450...should emulate a Computer Automated Technology CAT-1000 grandfather clock feature, but produces clipped audio and completes one or two tone sequences before playing what remains in its buffer endlessly. Results vary.node504381*CLI> rpt cmd 504381 cop 48 6,5,4,5,6,6,6,5,5,5,6,#,#...should whimsically play 'Mary Had a Little Lamb' in DTMF, but produces 6, 5, may skip other digits, perhaps #, and stops. Results vary.Playing multiple sequences may even return chan_simpleusb errors, with Asterisk abruptly restarting:
Additional logging during observed behavior (from /var/log/asterisk/messages.log):
Expected Behavior
cop,48 should playback with fidelity, no choppiness, and be able to handle all buffered tone sequences without clipping, halting, and observing internal timings for pre-defined sequences (either DTMF) or timings declared in explicit timings. It should be noted that precision values in previous versions of app_rpt with decimal values were played back; whether rounded to the nearest cycle or generated with precision remains to be seen.
Screenshots
No screenshots are available for this report.
Software Versions
Have you run a software update and rebooted?
YES
Platform
Additional context
It is not readily known whether this is fully reproducible on X86_64 platforms, but should be tested. It is also not known whether this is specific to or extends beyond chan_simpleusb.
The text was updated successfully, but these errors were encountered: