ESP8266 Community Forum

- Tue Oct 07, 2014 8:31 am #1373

Another point, other that the datasheet mention of I2S support, AFAIK we have zero info on it.

But we may have a hint. There are functions listed in the linker script that seem to be used for SIP:

Code: Select allsip_alloc_to_host_evt
sip_get_ptr
sip_get_state
sip_init_attach
sip_install_rx_ctrl_cb
sip_install_rx_data_cb
sip_post
sip_post_init
sip_reclaim_from_host_cmd
sip_reclaim_tx_data_pkt
sip_send
sip_to_host_chain_append
sip_to_host_evt_send_done
slc_add_credits


If those are indeed meant to be used for SIP as in "telephony", it would make sense to have some I2S stuff possible. It would also explain the language used about sound quality. Just look in the marketing blurb of you mobile phone, i'm sure they blather about excellent audio quality for telephony, and you can bet that such "excellent quality" is far from standard HiFi.

Greetings,

Chris

- Tue Oct 07, 2014 9:09 am #1374

Where do you find that the ESP8266 can receive data at 1400KB/s? That's 11Mb sustained throughput. Sure it can do that for one packet, but I have seen no evidence that is can sustain that for streaming. The benchmarks referenced in this thread show the measured ESP8266 streaming rate to be less than 1/10th that. It is common for Wifi chips to stream at data rates much lower than channel bandwidth. In fact it is fairly difficult to maintain streaming at minimum interpacket spacing. Now it may be possible to rewrite the TCP stack to achieve higher sustained rates, but rewriting a TCP stack in not something most hobbyist would undertake.

Plus we don't have nearly enough info on the radio hardware to undertake rewriting that stack. To implement minimal interpacket spacing the hardware has to have chained DMA packet buffers. No one know if this chip has those.

I got that from the netio bench I ran locally. netio uses multiple packets to test the speed, I would expect that behavior from any decent benchmarking tool. Wireshark analysis confirms this. More than 10000 packets were exchanged. So speed shown by netio can be taken as sustained speed.

Code: Select allNETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel

TCP connection established.
Packet size  1k bytes:  1282.54 KByte/s Tx,  4302 Byte/s Rx.
Packet size  2k bytes:  1288.54 KByte/s Tx,  4130 Byte/s Rx.
Packet size  4k bytes:  1285.79 KByte/s Tx,  17120 Byte/s Rx.
Packet size  8k bytes:  1272.92 KByte/s Tx,  15738 Byte/s Rx.
Packet size 16k bytes:  1274.67 KByte/s Tx,  15115 Byte/s Rx.
Packet size 32k bytes:  1281.12 KByte/s Tx,  13.99 KByte/s Rx.
Done.

BTW, I did get more than 1400 KB/s in an earlier benchmark, that's where the 1400 in my earlier comment comes from. 176 KB/s can be handled even without DMA IMHO.
So as of now, apart from lack of information about I2S, there is not enough data to write this module off. In fact all the data seems to suggest it is more than capable of streaming CD quality audio. Having said that, not all applications need 2 channel CD quality audio, some can get by even with phone quality. Some applications are so price sensitive that a difference of a few dollars does make a difference. In short, if this chip supports I2S there will be many interested in using it even if it is a compromise in some respect.

- Tue Oct 07, 2014 12:06 pm #1380

Where do you find that the ESP8266 can receive data at 1400KB/s? That's 11Mb sustained throughput. Sure it can do that for one packet, but I have seen no evidence that is can sustain that for streaming. The benchmarks referenced in this thread show the measured ESP8266 streaming rate to be less than 1/10th that. It is common for Wifi chips to stream at data rates much lower than channel bandwidth. In fact it is fairly difficult to maintain streaming at minimum interpacket spacing. Now it may be possible to rewrite the TCP stack to achieve higher sustained rates, but rewriting a TCP stack in not something most hobbyist would undertake.

Plus we don't have nearly enough info on the radio hardware to undertake rewriting that stack. To implement minimal interpacket spacing the hardware has to have chained DMA packet buffers. No one know if this chip has those.

I got that from the netio bench I ran locally. netio uses multiple packets to test the speed, I would expect that behavior from any decent benchmarking tool. Wireshark analysis confirms this. More than 10000 packets were exchanged. So speed shown by netio can be taken as sustained speed.

Code: Select allNETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel

TCP connection established.
Packet size  1k bytes:  1282.54 KByte/s Tx,  4302 Byte/s Rx.
Packet size  2k bytes:  1288.54 KByte/s Tx,  4130 Byte/s Rx.
Packet size  4k bytes:  1285.79 KByte/s Tx,  17120 Byte/s Rx.
Packet size  8k bytes:  1272.92 KByte/s Tx,  15738 Byte/s Rx.
Packet size 16k bytes:  1274.67 KByte/s Tx,  15115 Byte/s Rx.
Packet size 32k bytes:  1281.12 KByte/s Tx,  13.99 KByte/s Rx.
Done.

BTW, I did get more than 1400 KB/s in an earlier benchmark, that's where the 1400 in my earlier comment comes from. 176 KB/s can be handled even without DMA IMHO.
So as of now, apart from lack of information about I2S, there is not enough data to write this module off. In fact all the data seems to suggest it is more than capable of streaming CD quality audio. Having said that, not all applications need 2 channel CD quality audio, some can get by even with phone quality. Some applications are so price sensitive that a difference of a few dollars does make a difference. In short, if this chip supports I2S there will be many interested in using it even if it is a compromise in some respect.

Look at your benchmark -- you are not getting 1400KB/s for RX which is what streaming needs. You are getting 14KB/s. 100 times slower.
Maybe your benchmark program is wrong? Why are these so asymmetric?

Where I get my modules

- Tue Oct 07, 2014 1:31 pm #1384 Since the tool is run from PC then isn't TX = module RX? And the difference is because the module is dropping packets it can't buffer and retransmit? Which doesn't necessarially mean it can't dump them to a hardware bus.