Closed masterxq closed 1 year ago
Thank you for your contribution. Hopefully this will be something that Philippe will take the time to consider, when he has chance
Thanks, seems great - have you tried it with the complete squeezelite-esp32 to measure the global cpu gain? I've not checked how much this loops weights in the cpu load vs the fact that we have to 4x i2s rate
I'm very sorry, I have no environment for testing it and have very limited knowledge about your project, just read the i2s/spdif part, what really was helpful by understanding what I have to do... I have written my own libs and using some adf libs. What maybe is partly a bit sad, because I think there is high quality code in your project available, and I did fix the same issues as you did. But the problem remains the same, I have to know what issues exist before they can be fixed, after understanding the issues, is often easier to write the solution than search and integrate existing solutions. And it's less difficult to fix upcoming issues ^^
But what I can do, is sending you my complete testing app, then you can implement your algorithm correctly or make the test function respect the offset in your generated data and handle it correctly, what probably is the concern with the failed validation additional you can test the performance of upcoming code. The app is just quick and dirty but meets the requirements, only want to do basic tests, as this is only 1% of my project ^^
If you want we can stay in contact to avoid redundant work in the future :)
My focus are hardware solutions, and I'm facing audio hardware from time to time.
Thanks, seems great - have you tried it with the complete squeezelite-esp32 to measure the global cpu gain? I've not checked how much this loops weights in the cpu load vs the fact that we have to 4x i2s rate
Sorry my other answer is still correct, but did reread, and I have at least some information about the CPU usage, it needs about 10-12% (freertos taskmanager) of a single core in my application, but I'm still using i2s_write, what copies the buffer once more, what is not needed as long I remember from another project, it should be possible to just queue some buffers without copy them once more and directly handle them over to dma (no cpu), what makes much more sense. I can't remember what you are doing... The last measurement was before I wrote the new algorithm, I think it should save about 1-2% what is ok but not solves problems in the most cases. For me, it was more important to understand what's happening and have my data under control, being able to handle variable streams and have clean samples, maybe this can solve problems for some people, at least I have a better feeling with it :) (related to my projects and my understanding of my projects) Ofc I complete see your arguments that noise in the LSB can not be heard!
Best Regards
I really wonder, but it seems like I did remember wrong, here are my esp32 CPU stats. And I'm still using i2s_write. My modifications should not be in a visible range if the total usage is 2%...
But ok, the vTaskGetRunTimeStats
measures the stats since boot, right after how long I need to play a song after boot and how long time I wait before calling vTaskGetRunTimeStats
the stats will vary. However I2S will never reach 10% or more.
(44,1 kHz 320 kBit/s mp3, streamed over https)
I was that sure it was more than 10%. But ok it's not, at least no longer^^
Maybe I had a mistake in my code on my last measurement.
@masterxq do you feel is't something worth exploring?
@masterxq do you feel is't something worth exploring?
As the algorithm is completed and this will save bus time, cpu time and give better samples (the least significant bits are not random) and is easier to maintain (less hacky) and expand (eg other sample width). I would implement it, maybe not as high priority task, but I would do it :) And I have in my audio toolchain. It's working flawless from day one.
But at the end it is up to you :) I just want to share my code, as yours helped me to understand the problem :)
@masterxq thank you for exploring these improvements. Il see if/when we can get to it.
Given that the solution is 16 bits, this isn't going to work for us. Closing
Hey bois*, Tonight I had time to learn spdif, and I wrote an optimized implementation of the spdif convertion algorithm. As it not matches all your requirements (only 4 byte samples) I would like to post it here, so you have the option to use it.
I measured the speed of multiple algorithm, currently this on is the winner. This was the test conditions:
Results:
88 us
73 us
56 us
Additionally, this algorithm fixes some problems:
It brings one new potential problem:
Both points should be easy to change or implement.
Phillippe44 algorithm did not parse the verification, what most likely was An mistake of me by reimplementing it to my test application. But maybe this should be checked, I will attach my validation code.
What was tested:
What was not tested:
Fell free to use this code as and where you want. If you have a good day, then mention where it comes from :)
I will post here if i find issues or have optimizations.
Here is the code
The validator.
Hopefully this helps somebody!
Best regards and happy hacking!