DIY WiSA Home Theater system

[Glider95]

Here is an updated idea of architecture:

Missing:
- Cavern decoding on Linux
- I think ESP32 Snapclient is not set for I2S TDM
- Channel management of the TAS5805M DSP

Tried:
- Snapcast stream of a WAV 48Khz - 8 channel seems to be okay (quick trial on Pi yesterday)

Before investing more money in hardware, a Windows setup could be tried with Cavern -> Snapcast -> Snapclient

 

[phofman]

There would be quite a few buffers involved, I would guess the audio latency making not negligible. A good video player can delay the video by a configured time, but that requires the audio latency to be reasonably constant between restarts. Movie playback with this long audio chain may be peculiar...

 

[Glider95]

From my understanding, Snapcast also allows buffering so if:
- Audio player is set to 500ms delay
- Snapcast is also set to 500ms buffering and then time-sync streaming
This should be enough to sync both ? But again, that's in theory, only real test can tell.

Update on Cavern: Thanks to @VoidX, the CavernPipe which is the conversion/rendering pipeline is now multiplatform !

 

[Glider95]

Some trial with the new ESP32-C5 Dev boards:

Managed to build snapclient after some modifications and I can connect to 5GhZ & receive the 8 channel audio:

I (14580) WIFI: connected to ap SSID: Breizh 5Ghz
I (14580) SC: Connected to AP
I (14590) HTTP: Initializing SPIFFS
I (14610) HTTP: Partition size: total: 534881, used: 50200
I (14610) HTTP: Mount /html to storage success

W (14810) wifi:<ba-add>idx:0, ifx:0, tid:0, TAHI:0x100d0f6, TALO:0xe532166c, (ssn:5, win:64, cur_ssn:5), CONF:0xc0000001
I (14820) SC: Buffer length: 1000
I (14820) SC: Latency: 0
I (14820) SC: Mute: 0
I (14820) SC: Setting volume: 100
I (14840) SC: Audio settings: mute=0, volume=100
I (14850) SC: fLaC sampleformat: 48000:16:8
I (14910) PLAYER: player_setup_i2s: dma_buf_len is 576, dma_buf_count is 4, sample rate: 48000, bits: 16
W (14910) PLAYER: no pcm chunk queue created?
I (14910) PLAYER: created new queue with 40
I (14910) PLAYER: snapserver config changed, buffer 1000ms, chunk 1152 frames, sample rate 48000, ch 8, bits 16 mute 0 latency 0
I (14920) SC: Audio settings: mute=1, volume=100
I (15110) SC: latency buffer full
I (15140) PLAYER: DMA completely loaded
W (15530) PLAYER: couldn't get memory to insert chunk, inserting an chunk containing just 0
W (15530) PLAYER: 25156, 15360, 0, 0

However, as expected the ESP onboard RAM is too limited to store enough buffer.
The dev board comes with 8MB of PSRAM so that should be enough to store, but need to work on making the change

 

[Glider95]

Re-starting from Esparagus Snapclient fork (instead of main project ), I am able to leverage the PSRAM available on the Dev board and which is enough to not overload the buffer !

On the other side, I have succesfully chained CavernPipe (File -> pipe -> Snapserver) for real-time E-AC3 decoding and streaming !

Sorry the pictures are just screenshots as there is not much to show...

EDIT:
Receiving the rendered CavernPipe audio on the ESP

 

[sonocotta]

Thank you for your feedback !

If you are referring to this strip:
View attachment 410778

I believe it used for cooling of the chip itself. I forgot where I read that but I remember something around that line.

As you mentioned in your edit, the chip is capable of 100W mono output. Upon your feedback and also received from the subreddit comments (posted as you advised ) , I believe I might have to oversize a bit the traces and input connector to handle up to 24V input power.
Personally, I don't think I will go up high in output power as the most consuming part of my speakers would be 2 ways bookshelf ( I am looking at this base build : Erikdidit - bookshelf - Video) for around 50W.

I might be a little late to the party, but I wanted to share nevertheless.

The major flow of that design is heat management. This DAC is going to produce 10-20W of heat at full blast. I did power tests with TAS5805M DAC that is very close to both 5825 and 5828, and despite having a large heat dissipation zone on the back of the DAC, I cannot get it past ~30W of power on the speakers without getting into overtemp protection.
More importantly, 5828 is a top-side thermal pad, which means top-side heat management is not optional Either you go through a custom-designed and expencive heat plate, or you need to get rid of all high caps around the DAC so you can fix some off-the-shelf aluminum radiator. Ideally, create some mounting holes as well.
Although for testing and prototyping it should not be an issue

 

[Glider95]

I might be a little late to the party, but I wanted to share nevertheless.

The major flow of that design is heat management. This DAC is going to produce 10-20W of heat at full blast. I did power tests with TAS5805M DAC that is very close to both 5825 and 5828, and despite having a large heat dissipation zone on the back of the DAC, I cannot get it past ~30W of power on the speakers without getting into overtemp protection.
More importantly, 5828 is a top-side thermal pad, which means top-side heat management is not optional Either you go through a custom-designed and expencive heat plate, or you need to get rid of all high caps around the DAC so you can fix some off-the-shelf aluminum radiator. Ideally, create some mounting holes as well.
Although for testing and prototyping it should not be an issue

For now, I will follow your implementation with TAS5805M.
TAS5828M does not bring much added value (slightly higher output power but as you said, it comes with heat) but it comes with an issue of I2C control, from what I understand, which you managed to overcome with your TAS5805M.
In addition, I am planning to use one board per speaker so in Mono BTL, so could go up to almost 45W per speaker (if I am not wrong? 2*23W = 1*40W in term of heat?)
One complexity at a time, as there is already a few piling up !

@sonocotta: If you are interested, I do have access to the Texas Instrument software (but no EV board).

 

[sonocotta]

For now, I will follow your implementation with TAS5805M.
TAS5828M does not bring much added value (slightly higher output power but as you said, it comes with heat) but it comes with an issue of I2C control, from what I understand, which you managed to overcome with your TAS5805M.
In addition, I am planning to use one board per speaker so in Mono BTL, so could go up to almost 45W per speaker (if I am not wrong? 2*23W = 1*40W in term of heat?)
One complexity at a time, as there is already a few piling up !

@sonocotta: If you are interested, I do have access to the Texas Instrument software (but no EV board).

Thanks, I have PuraPath as well. I would not have managed to create tas5805m driver without it. I will create an equivalent driver for the tas5825/28 as well, hopefully somewhere before the end of this year. I will publish a new board based on the TAS5825M. Reach out when you're ready with the software part, I'll do my best to help with hardware

 

[Glider95]

Thanks, I have PuraPath as well. I would not have managed to create tas5805m driver without it. I will create an equivalent driver for the tas5825/28 as well, hopefully somewhere before the end of this year. I will publish a new board based on the TAS5825M. Reach out when you're ready with the software part, I'll do my best to help with hardware
View attachment 474007

As you can see, I have started this idea a year ago and did not progress much ! You will be done before me

The board you are showing here is the prototype for ESP32-S3 + TAS5825M ?

 

[sonocotta]

As you can see, I have started this idea a year ago and did not progress much ! You will be done before me

The board you are showing here is the prototype for ESP32-S3 + TAS5825M ?

No worries, I'm not in rush, just trying to help
It is good old ESP32 and TAS5825M. But I can fairly easily change to S3 or C5, whichever is your final choice.

 

[Hayabusa]

I have not look into AES67/Date as:
- Power outlet is not really an issue in my setup but running other type of cable is not possible.

You can get your lan connection via the power line:
https://homegridforum.org/

 

[Glider95]

You can get your lan connection via the power line:
https://homegridforum.org/

I think that's the traditional PCL technology ?
There is a company using this kind of technology: https://www.audiocu.com/

 

[Hayabusa]

I think that's the traditional PCL technology ?
There is a company using this kind of technology: https://www.audiocu.com/

Its not PCL but the newer GiGAWire™ (G.hn Access)

 

[Glider95]

I have successfully piped data from a Demo .mkv file to CavernPipe out to Snapserver, on a Raspberry Pi 4: Cavern-Snapserver-Pipeline
I had to create some pipe bridges to have this flow: FFmpeg -> Pipe input -> CavernPipeServer -> PipeToFifo -> Snapserver, and it works : Wireless rendered Dolby real time !

Next step is to use VLC as Media Player and a virtual cable with ALSA to feed in the pipe input (instead of a ffmpeg command line)
I feel the sound is also not exactly as the original media, low frequencies feels different so I will have to investigate what are the settings possible.

 

[djtwxj]

I have successfully piped data from a Demo .mkv file to CavernPipe out to Snapserver, on a Raspberry Pi 4: Cavern-Snapserver-Pipeline
I had to create some pipe bridges to have this flow: FFmpeg -> Pipe input -> CavernPipeServer -> PipeToFifo -> Snapserver, and it works : Wireless rendered Dolby real time !

Next step is to use VLC as Media Player and a virtual cable with ALSA to feed in the pipe input (instead of a ffmpeg command line)
I feel the sound is also not exactly as the original media, low frequencies feels different so I will have to investigate what are the settings possible.

Hi Glider95:
two questions
1 can help build a Win x64 cavernpipe?
2 is it possible to capture hdmi bitstream audio use ESP32？then pipe out to win x64 cavern

 

[phofman]

is it possible to capture hdmi bitstream audio use ESP32？

E.g. HDMI 720p24 has over 900Mbps - audio is part of that stream and must be demultiplexed. Receiving HDMI audio requires a dedicated hardware - either special chips which output audio on I2S (used in HDMI-I2S extractors commonly available), or an integrated HDMI receiver in modern ARM SoCs (e.g. RK3588 - also 8ch I2S port internally), or some custom chips (likely used in AV receivers).

 

[voodooless]

Just get an HDMI capture card... But most won't capture HDCP content, and bitstream audio might be another issue, as will be (e)ARC.

 

[Glider95]

Hi Glider95:
two questions
1 can help build a Win x64 cavernpipe?
2 is it possible to capture hdmi bitstream audio use ESP32？then pipe out to win x64 cavern

Hello,

1. I have a ask Copilot to work on that: https://github.com/Glider95/Cavern-Snapserver-Pipeline/pull/2

2. You would like to extract the Dolby bitstream from an HDMI signal ?
I think @phofman and @voodooless made good points here. That's why software capture/sink is a bit easier here...

 

[MCH]

@Glider95 are you satisfied with the esp32-c5? I read that early modules achieved similar performance than the existing 2.4 chips...
Also, maybe I have missed it, do all modules receive all channels? I guess yes but wanted to confirm.
Thanks!

 

[Glider95]

@Glider95 are you satisfied with the esp32-c5? I read that early modules achieved similar performance than the existing 2.4 chips...
Also, maybe I have missed it, do all modules receive all channels? I guess yes but wanted to confirm.
Thanks!

I have just quickly tested it and tried to adapt Snapclient on it.
In term of performance vs 2.4Ghz, you mean in term of Wifi speed ?

In the idea I have in mind, yes all modules would receive all 8 channels (should be around 8mb/s with overhead) and then the channel selection will done via the DSP of the DAC !