Closed 0x0fe closed 1 year ago
ok, i did not knew there was an old and a new I2S API, i will to try to find one library which uses the "new" API to see if it makes any difference. i tried this other library for testing playback seek https://github.com/schreibfaul1/ESP32-audioI2S/issues/508 , unfortunately as soon as the seek function is called it loops forever on the current buffer, so i could not really test and i am not sure it uses a different I2S API, the I2S configuration structures and methods seems identical at least.
I was kinda able to implement seek on your library, it "works" although it is not quite smooth, and even tho most glitches are solved by modifying the buffer sizes there is still few random occurences. https://github.com/pschatzmann/arduino-audio-tools/discussions/579#discussioncomment-5361985
nice, i will try to figure how to test with this API instead. edit: Well, i guess Arduino core does not use a version of the IDF which includes this new I2S API:
I changed the AudioKitStream implementation to use reuse the I2SStream and was running into some strange repeating noise when the cfg.auto_clear was not set to true. Maybe this is the issue here as well...
You really know you’re I2s!
On Tue, Mar 21, 2023 at 10:50 AM Phil Schatzmann @.***> wrote:
I changed the AudioKitStream implementation to use reuse the I2SStream and was running into some strange repeating noise when the cfg.auto_clear was not set to true. Maybe this is the issue here as well...
— Reply to this email directly, view it on GitHub https://github.com/pschatzmann/arduino-audio-tools/issues/659#issuecomment-1478341937, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE5D76ZAZ7T7WTOTHF6LZTW5HS7FANCNFSM6AAAAAAVNWJWXM . You are receiving this because you are subscribed to this thread.Message ID: @.***>
-- Kelly Eldritch
@.***
THis could be the same problen that has plagued so many of us using I2s to play audio. THe Internet is loaded with people complaining about crackling in the audio and pop (farts?) between tracks. Thanks to our host here, the real cause is now known!
For reasons that are beyond my programming skills, the header information at the beginning of all the files after the first one, (and maybe even the first one) are being played! That is noise and 44 bytes long. Hence the pop/fart. Either the first part of the file has to be muted or the first 44 bytes have to skipped over.
I will leave it to Mr. Schatzmann to explain further.
No, but it could be RDJunc's problem with cables that are too long, that can be addressed with a resistor.
When using a WAV data it is critical that the audio stream starts with a WAV header and subsequently only contains audio data. If your data stream suddenly contains a new WAV Header this is interpreted as audio data which creates noise!
WAV files follow this convention and the audio player automatically handles the correct processing of a new file which starts with a header that might change the sample rate, channels or bits_per_sample.
So, this is not a new issue, and i still can't figure it out nor find a solution, when i use the transport functions, namely Next, Previous and Play/pause, i get digital "fart" noises. I have tried to use the mute, both manually and automatically by seting the mute pin in config, without success. When used manually it doesnt work because i probably cant make the muting at the right time to hide these audio artefacts, when using the automatic mute it does not do anything on this issue.
The fart noises when switching between songs are of variable intensity, proportional to the player volume. when using stop/play the are stronger, but still totally linked to the player volume.
By the sound of it it seems like there is a discontinuity to the data feeding at the end, for example when player.stop() is called there is a silence followed by few more chunk of data and then silence. The fart noise is these few chunk of data/silence most likely. I have tried various methods to correct this, so far without success.
Attached is an audio sample of the problem.
Here is how the transport functions are handled, in this test case directly from the main loop, which also handles player.copy(). Also the mute function (mute pin of the audio PA) is perfectly clean when operated right in the middle of the playback manually, so if i dont have any other option i will have to use that, but i really would prefer to fix the problem at the root, i dont understand what is going on but something is not right with the datas sent to the DAC when usin stop, next and previous.
Audio.zip