About examples->WebRadioDemo

[nopnop2002]

Hello.

client.read() also reads the HTTP header.

There is no fatal problem, but you can exclude the HTTP header as follows.

My Code:

void HexDump(uint8_t * mp3buff, uint8_t bytesread) {
  int loop = (bytesread + 9) / 10;
  uint8_t index = 0;
  char str[20];
  //Serial.print("bytesread=");
  //Serial.println(bytesread);
  Serial.println();
  for (int i=0;i<loop;i++) {
    for(int j=0;j<10;j++) {
      if (index < bytesread) {
        if (mp3buff[index] < 0x10) Serial.print("0");
        Serial.print(mp3buff[index], HEX);
        Serial.print(" ");
        if (mp3buff[index] >= 0x20 && mp3buff[index] <= 0x7F) {
          str[j] = mp3buff[index]; 
        } else {
          str[j] = 0x20;
        }
        str[j+1] = 0;
        index++;
      }
    }
    Serial.println();
    Serial.println(str);
    delay(1);
  }
}



uint8_t IsHeaderEnd(uint8_t * mp3buff, uint8_t bytesread) {
  static char previus = 0;
  static int status = 0;
  for(int i=0;i<bytesread;i++) {
    if (mp3buff[i] == 0x0D) {
      Serial.print("0D i=");
      Serial.print(i);
      Serial.print(" previus=");
      Serial.println(previus,HEX);
      if (previus != 0x0A) status=0;
      if (previus == 0x0A) status++;
    }
    if (mp3buff[i] == 0x0A) {
      Serial.print("0A i=");
      Serial.print(i);
      Serial.print(" status=");
      Serial.print(status);
      Serial.print(" previus=");
      Serial.println(previus,HEX);
      if (previus == 0x0D) status++;
      if (status == 3) return i+1;
    }
    previus = mp3buff[i];
  }
  return 0;
}


void loop() {
    static uint8_t startData;
    static bool detectedHeader = false;
    
    if(!client.connected()){
      Serial.println("Reconnecting...");
      if(client.connect(host, httpPort)){
        client.print(String("GET ") + path + " HTTP/1.1\r\n" +
                  "Host: " + host + "\r\n" + 
                  "Connection: close\r\n\r\n");
      }
    }
  
    if(client.available() > 0){
      // The buffer size 64 seems to be optimal. At 32 and 128 the sound might be brassy.
      uint8_t bytesread = client.read(mp3buff, 64);
      startData = 0;
      if (!detectedHeader) {
        HexDump(mp3buff, bytesread);
        startData = IsHeaderEnd(mp3buff, bytesread);
        Serial.print("startData=");
        Serial.println(startData);
        if (startData > 0) detectedHeader = true;
      }

      player.playChunk(&mp3buff[startData], bytesread);
    }
}

Test result:

Simple Radio Node WiFi Radio
Connecting to SSID aterm-d5a4ee-g
.....WiFi connected
IP address: 
192.168.10.121
connecting to ice2.somafm.com
Requesting stream: /seventies-128-mp3

48 54 54 50 2F 31 2E 31 20 32 
HTTP/1.1 2
30 30 20 4F 4B 0D 0A 43 6F 6E 
00 OK  Con
74 65 6E 74 2D 54 79 70 65 3A 
tent-Type:
20 61 75 64 69 6F 2F 6D 70 65 
 audio/mpe
67 0D 0A 44 61 74 65 3A 20 4D 
g  Date: M
6F 6E 2C 20 30 39 20 4D 61 72 
on, 09 Mar
20 32 30 32 
 202
0D i=15 previus=4B
0A i=16 status=0 previus=D
0D i=41 previus=67
0A i=42 status=0 previus=D
startData=0                    ------> Not detect end of HTTP header

30 20 31 30 3A 35 38 3A 33 36 
0 10:58:36
20 47 4D 54 0D 0A 69 63 79 2D 
 GMT  icy-
62 72 3A 31 32 38 0D 0A 69 63 
br:128  ic
79 2D 67 65 6E 72 65 3A 4D 65 
y-genre:Me
6C 6C 6F 77 20 37 30 73 0D 0A 
llow 70s  
69 63 79 2D 6E 61 6D 65 3A 4C 
icy-name:L
65 66 74 20 
eft 
0D i=14 previus=54
0A i=15 status=0 previus=D
0D i=26 previus=38
0A i=27 status=0 previus=D
0D i=48 previus=73
0A i=49 status=0 previus=D
startData=0                    ------> Not detect end of HTTP header

43 6F 61 73 74 20 37 30 73 3A 
Coast 70s:
20 4D 65 6C 6C 6F 77 20 61 6C 
 Mellow al
62 75 6D 20 72 6F 63 6B 20 66 
bum rock f
72 6F 6D 20 74 68 65 20 53 65 
rom the Se
76 65 6E 74 69 65 73 2E 20 59 
venties. Y
61 63 68 74 20 66 72 69 65 6E 
acht frien
64 6C 79 2E 
dly.
startData=0                    ------> Not detect end of HTTP header

20 5B 53 6F 6D 61 46 4D 5D 0D 
 [SomaFM] 
0A 69 63 79 2D 6E 6F 74 69 63 
 icy-notic
65 31 3A 3C 42 52 3E 54 68 69 
e1:<BR>Thi
73 20 73 74 72 65 61 6D 20 72 
s stream r
65 71 75 69 72 65 73 20 3C 61 
equires <a
20 68 72 65 66 3D 22 68 74 74 
 href="htt
70 3A 2F 2F 
p://
0D i=9 previus=5D
0A i=10 status=0 previus=D
startData=0                    ------> Not detect end of HTTP header

77 77 77 2E 77 69 6E 61 6D 70 
www.winamp
2E 63 6F 6D 2F 22 3E 57 69 6E 
.com/">Win
61 6D 70 3C 2F 61 3E 3C 42 52 
amp</a><BR
3E 0D 0A 69 63 79 2D 6E 6F 74 
>  icy-not
69 63 65 32 3A 53 48 4F 55 54 
ice2:SHOUT
63 61 73 74 20 44 69 73 74 72 
cast Distr
69 62 75 74 
ibut
0D i=31 previus=3E
0A i=32 status=0 previus=D
startData=0                    ------> Not detect end of HTTP header

65 64 20 4E 65 74 77 6F 72 6B 
ed Network
20 41 75 64 69 6F 20 53 65 72 
 Audio Ser
76 65 72 2F 4C 69 6E 75 78 20 
ver/Linux 
76 31 2E 39 2E 35 3C 42 52 3E 
v1.9.5<BR>
0D 0A 69 63 79 2D 70 75 62 3A 
  icy-pub:
30 0D 0A 69 63 79 2D 75 72 6C 
0  icy-url
3A 68 74 74 
:htt
0D i=40 previus=3E
0A i=41 status=0 previus=D
0D i=51 previus=30
0A i=52 status=0 previus=D
startData=0                    ------> Not detect end of HTTP header

70 3A 2F 2F 73 6F 6D 61 66 6D 
p://somafm
2E 63 6F 6D 0D 0A 53 65 72 76 
.com  Serv
65 72 3A 20 49 63 65 63 61 73 
er: Icecas
74 20 32 2E 34 2E 30 2D 6B 68 
t 2.4.0-kh
31 30 0D 0A 43 61 63 68 65 2D 
10  Cache-
43 6F 6E 74 72 6F 6C 3A 20 6E 
Control: n
6F 2D 63 61 
o-ca
0D i=14 previus=6D
0A i=15 status=0 previus=D
0D i=42 previus=30
0A i=43 status=0 previus=D
startData=0                    ------> Not detect end of HTTP header

63 68 65 2C 20 6E 6F 2D 73 74 
che, no-st
6F 72 65 0D 0A 41 63 63 65 73 
ore  Acces
73 2D 43 6F 6E 74 72 6F 6C 2D 
s-Control-
41 6C 6C 6F 77 2D 4F 72 69 67 
Allow-Orig
69 6E 3A 20 2A 0D 0A 41 63 63 
in: *  Acc
65 73 73 2D 43 6F 6E 74 72 6F 
ess-Contro
6C 2D 41 6C 
l-Al
0D i=13 previus=65
0A i=14 status=0 previus=D
0D i=45 previus=2A
0A i=46 status=0 previus=D
startData=0                    ------> Not detect end of HTTP header

6C 6F 77 2D 48 65 61 64 65 72 
low-Header
73 3A 20 4F 72 69 67 69 6E 2C 
s: Origin,
20 41 63 63 65 70 74 2C 20 58 
 Accept, X
2D 52 65 71 75 65 73 74 65 64 
-Requested
2D 57 69 74 68 2C 20 43 6F 6E 
-With, Con
74 65 6E 74 2D 54 79 70 65 0D 
tent-Type 
0A 41 63 63 
 Acc
0D i=59 previus=65
0A i=60 status=0 previus=D
startData=0                    ------> Not detect end of HTTP header

65 73 73 2D 43 6F 6E 74 72 6F 
ess-Contro
6C 2D 41 6C 6C 6F 77 2D 4D 65 
l-Allow-Me
74 68 6F 64 73 3A 20 47 45 54 
thods: GET
2C 20 4F 50 54 49 4F 4E 53 2C 
, OPTIONS,
20 48 45 41 44 0D 0A 43 6F 6E 
 HEAD  Con
6E 65 63 74 69 6F 6E 3A 20 43 
nection: C
6C 6F 73 65 
lose
0D i=45 previus=44
0A i=46 status=0 previus=D
startData=0                    ------> Not detect end of HTTP header

0D 0A 45 78 70 69 72 65 73 3A 
  Expires:
20 4D 6F 6E 2C 20 32 36 20 4A 
 Mon, 26 J
75 6C 20 31 39 39 37 20 30 35 
ul 1997 05
3A 30 30 3A 30 30 20 47 4D 54 
:00:00 GMT
0D 0A 0D 0A FF FB 92 04 ED 0F -------> 0D 0A 0D 0A is end of HTTP header
          
F3 32 3F 55 83 38 42 E0 65 E7 
 2?U 8B e 
EA B0 65 E8 
  e 
0D i=0 previus=65
0A i=1 status=0 previus=D
0D i=40 previus=54
0A i=41 status=0 previus=D
0D i=42 previus=A
0A i=43 status=2 previus=D
startData=44                 -------> Detect end of HTTP header

[nopnop2002]

I don't think it needs to be fixed.

It works fine without any changes.

Please close after reading this issue.

[baldram]

Hi @nopnop2002! Thank you.
The community delivered the radio example. The author's idea was to provide a simple example. While people can extend it according to their needs, I think it's important to emphasise what are the potential issues to handle.
I will add a comment to the example pointing to this thread as well as the other one regarding buffer.

[nopnop2002]

Yes
I think it's important to provide a simple example.

[fabitom]

Yup, metadata while streaming are disabled by default on most servers. You can control this by "Icy-MetaData: 0" header.
Unhandled metadata will cause clicking. But support for metadata is not simple, you need additional buffer or ringbuffer, grap icy-metaint, skip metadata chunks, parse icy-* headers...

[philippedc]

Hi, I made several tries and I understand now why sometime the sound is brassy, and sometime it is clicking. Sorry but for my experience ring buffer does not solve my problem.

First: For some radios the sound is brassy. This is solve by increasing the buffer size : the brassy effect seems to be the routine is too low compare to the streaming. By increasing the buffer the client.read function is done less time, so it is faster.

Second: For some stations that make many clicking effect after a moment (few seconds to few minutes) the VS1053 crash, I must reboot to come back to make it running again.
To solve this problem, I add some delays: the SPI.writeBytes seems to need a while between 2 calls. So I modify the VS1053.cpp to the following:

void VS1053::sdi_send_buffer(uint8_t *data, size_t len) {
size_t chunk_length; // Length of chunk 32 byte or shorter

data_mode_on();
while (len >= vs1053_chunk_size ) // More to do?
{
    await_data_request(); // Wait for space available
    len -= vs1053_chunk_size;
    SPI.writeBytes(data, vs1053_chunk_size);
    delay(1);
    data += vs1053_chunk_size;
}
data_mode_off();

}

Third: I have told in another thread that when I compare a radio reception from the device and a PC, I noticed that the streaming from this web radio is much faster that on the PC. After a while the web radio either looses the signal, either crashes. Depending of the signal bitrate, the client.read should be cadenced at the right time. I do not know how to do, because for the moment I do not know how to automatically define how long client.read takes to fill its buffer.
However I test this code that makes to web radio working much better:

static byte tempo = 0;
if( tempo %2 == 0 ) { // it is not use to run each time
ArduinoOTA.handle(); // for code update available from wifi
server.handleClient(); // call to web server
}

// if signal is lost
if( !client.connected() ) {
WiFi.status(); // wifi connexion checkup
Serial.println("Tentative de reconnexion...");
if( client.connect(urlStation, portStation.toInt()) ) {
client.print(String("GET ") + pathStation + " HTTP/1.1\r\n" +
"Host: " + urlStation + "\r\n" +
"Connection: close\r\n\r\n");
}
return;
} // end of !client.connected() test

// if connected to the radio station :)
//if( client.available() > 0 ) { // not usefull
if( !pause && tempo%10 == 0 ) {
if( client.read(mp3buff, 256) == 256 ) {
delay(1);
player.playChunk(mp3buff, 256);
}
else player.playChunk(sampleMp3, sizeof(sampleMp3)); // for debugging if buffer is not full
}
tempo++;
} // end of loop

This code uses very short time of 'pause' that synchronize the streaming. To improve this code, tempo%10 == 0 should be define automatically depending of the data flow speed.

[fabitom]

Whey you send 256 buffer to VS1053 then sdi_send_buffer will split that buffer to 32 (vs1053_chunk_size) and will send to VS1053 in loop. sdi_send_buffer already have proper delay in await_data_request() function. When Delay(1) in sdi_send_buffer helps you then I don't understand why...
await_data_request checking dreq pin, in other words asking vs1053 if we can send new data.
Hm... it looks like something is not making proper clock speed.
Can you test only mono output ?

  write_register(0x07, 0x1e09);
  write_register(0x06, 0x0001);

[philippedc]

@fabitom include now in the VS1053::begin() function, however I don't notice significant improvement.

[fabitom]

Ok, you can try this:

if( client.available() > 0 ) {
...
} else {
Serial.print('.');
}

and watch if problems occour when client don't have data.

[philippedc]

I did similar yet:
// if connected to the radio station :)
if( client.available() > 0 ) {
if( !pause && tempo == 0 ) {
bytesread = client.read(mp3buff, 512);
delay(1);
player.playChunk(mp3buff, bytesread);
}
}
else player.playChunk(sampleMp3, sizeof(sampleMp3)); // for debugging if buffer is not full
tempo++;
if( tempo > 10 ) tempo=0;

I never hear the specific sampleMp3 when a radio is listened. So the client.available is always true, and in fact I do not understand this test must be performed each loop.
However tempo is required for these clicking radios can play for more than 10 minutes. I improve duration with 30, 40, 50 instead of 10, but in this case most of other radios become brassy....

[philippedc]

.... I cannot see the way Edzelf has coded the equivalent of the client.read in its Esp-radio....

[baldram]

@philippedc Thanks for this analysis.

To solve this problem, I add some delays: the SPI.writeBytes seems to need a while between 2
calls. So I modify the VS1053.cpp

Are you using ESP8266? Right?
I wonder whether instead of adding delay(1), the yield() would do the job?
Would you please check and adjust your VS1053.cpp modification?

AFIK the "yield" is designed to solve such issues (As described here, the reason for Yielding is preventing from various issues. The ESP8266 runs a lot of utility functions in the background – keeping WiFi connected, managing the TCP/IP stack, and performing other duties. Blocking these functions from running can cause the ESP8266 to crash and reset itself).

If the yield works fine, I would add it to VS1053.cpp before SPI.writeBytes like you did.

[fabitom]

.... I cannot see the way Edzelf has coded the equivalent of the client.read in its Esp-radio....

Esp-radio client.read

[philippedc]

@baldram it sounds much better !

If the yield works fine, I would add it to VS1053.cpp before SPI.writeBytes like you did.

il is after. I've also had a yield in the loop:
if( client.available() > 0 ) {
bytesread = client.read(mp3buff, 256);
yield();
player.playChunk(mp3buff, bytesread);
}

It make twenty minutes the web radio did not crash.
I have a remark: most of the time the crash consists of the infinite repetition of the a noise that could be the playChunk buffer. Why in this case the ESP8266 does not perform a watchdog reset as the loop is stopped ?

[philippedc]

.... there is no WD reset because of the yield() in await_data_request(); I suppose ?

[nopnop2002]

I will release the version corresponding to ESP-IDF.

https://github.com/nopnop2002/esp-idf-vs1053

It use RingBuffer.

But sometimes it lose network connection.

I don't know why.

Your modifications are welcome.