Repository navigation
Pin audiodsp at 4d6b62f and audioif at 7f1cd37: Ogg Vorbis files play, with the decoder in PSRAM on ESP32 (audiodsp#238, audioif#30) - #107
Merged
Conversation
…, with the decoder in PSRAM on ESP32 (audiodsp#238, audioif#30)
bdbarnett
added a commit
that referenced
this pull request
Oct 19, 2026
…give (#14) * _audioif.lock_probe(): ask FreeRTOS whether it refuses a non-owner's give audiodsp#107 fixed two nodes that released the pump lock without ever having taken it. On Windows that corrupted the CRITICAL_SECTION; glibc refuses a non-owner's unlock with EPERM, measured. That FreeRTOS refuses it too -- which is why neither ESP32 board ever showed the defect -- was read out of its source and never run (audiodsp#117). This runs it. The interpreter takes the real pump mutex, a second FreeRTOS task tries to give it, and the BaseType_t that comes back is the answer. It does the same again with nobody holding the mutex, because that is the shape #107's nodes were actually in -- a release with no take anywhere, rather than a release of somebody else's take. It is C rather than a script because the question is about a task that is not the owner, which Python here cannot arrange: this port's `_thread` lock is a binary semaphore, which has no owner at all and would answer a different question very convincingly. Safe to run. `xQueueGiveMutexRecursive` compares the holder against the current task and returns pdFAIL when they differ; it does not assert. Nothing in the audio path calls this. * lock_probe: a control that must return 1 0 is what the FreeRTOS source predicts for both questions this asks, so a probe that never ran, or whose give was broken for an unrelated reason, returns exactly the expected answer and cannot be told from the truth. That is this workspace's signature failure and it is not worth shipping a number that has it. So there is a third leg: a task that TAKES the mutex itself and then gives it back, which must come back 1. A probe that cannot produce a 1 has not been shown to be able to answer anything.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Firmware built from these pins has
audiovorbis.VorbisDecoder, which plays Ogg Vorbis files whereveraudiomp3.MP3Decoderplays an MP3 (PyDevices/audiodsp#238). On ESP32 boards the decoder's state goes to PSRAM through audioif's new memory hooks (PyDevices/audioif#30).The audiodsp move also brings audiodsp#237 (a Convolver reload keeps the audio in flight). The decoder adds about 90 KB to an ESP32-P4 image.