A way to suppress the glitches and other streaming troubles

[philippedc]

Hi, I love the baldam exemple web radio. I built 3 of them. Unfortunately I have 2 problems with this code, especially with French radio station:

• a particular station is difficult to connect, when I'm lucky it is connected but after a while it is definitively disconnected. It is
  http://live02.rfi.fr/rfiafrique-64.mp3
• other stations well start, but after a dozen of seconds have many glitches, until they make the device aborting. they are for instance (64K / 128K):
  http://icecast.radiofrance.fr/franceinter-lofi.mp3 or http://icecast.radiofrance.fr/franceinter-midfi.mp3
  http://icecast.radiofrance.fr/franceculture-lofi.mp3 or http://icecast.radiofrance.fr/franceculture-midfi.mp3
  https://icecast.radiofrance.fr/fip-lofi.mp3 or https://icecast.radiofrance.fr/fip-midfi.mp3

I have spent may be an hundred of hours to try to solve this problem. I thank wmarkow and fabitom for their help. In #51 they tried several workarounds like round buffer, but are mostly incomprehensible for my basic level of programming. But I learnt the following:
The glitches are due to \r\nX\r\n sequences, and then it looks like the streaming is chunked.
Works had been done to suppress these chunk messages, see #48, but I still have glitches for these particular French radios. Moreover, wmarkow and fabitom confirm that their codes are working well for themselves, but not for me :(

There is not many information about chunked transfer data, except this https://en.wikipedia.org/wiki/Chunked_transfer_encoding
When you read in detail, follow the links, you will find that chunked data stream is mostly for video transfer, here it is sound only, so I'm wondering if these chunks are not fake.... AND chunked transfer is only supported for HTTP1.1. Not in HTTP1.0

EUREKA !

@baldram I suggest to replace:

client.print(String("GET ") + path + " HTTP/1.1\r\n" +
                 "Host: " + host + "\r\n" +
                 "Connection: close\r\n\r\n");

with:

client.print(String("GET ") + path + " HTTP/1.0\r\n" +
                 "Host: " + host + "\r\n" +
                 "Connection: close\r\n\r\n");

It is a miracle: no more glitches, no lost stations, everything is fine now :)

[fabitom]

Probably with http/1.0 server sending not chunked stream because 1.0 doesn't support chunked transfer encoding.

[baldram]

I love the baldam exemple web radio.

In fact, the radio example was delivered by vincegellar based on his hardware+software project (using this vS1053 library).

Moreover, wmarkow and fabitom confirm that their codes are working well for themselves, but not for me :(

Maybe it's also about the hardware. There is a number of different boards.
I will try also with one of my boards for mentioned radio stations.

I'm wondering if these chunks are not fake.... AND chunked transfer is only supported for HTTP1.1. Not in HTTP1.0 EUREKA !

Ok, this is also the way to work around the problem.
I had a look to Edzelf and he is using HTTP/1.1. So maybe I will just add a comment to the radio example code to suggest experimenting also with HTTP/1.0. I will also add a reference to this issue and other issues where additional solutions were discussed.

Probably http/1.0 doesn't support chunked transfer encoding.

Hmm, this might be the thing. The good is that workaround works.

[ewbarnes53]

I ran the WebRadioChunked sketch, and to my ear, it sounds much better. My wife is a trained professional musician, and she reported that it sounded worse than the original, non-chunked radio.

I say it sounds better, because there is less of the clicking going on. I found that very annoying.

But my wife may have a point. It may be that the chirping and burbling on this version is more frequent. I am not sure how to best describe the sound, I don't know how to make a recording.

I would say that the audio has a watery sound, some times. Like a singer trying to sing with a mouth full of water.

So thanks for the updated code. It sounds better to me.

[philippedc]

the watering effect may be due by a part of the streaming is lost. I made tests to listen a stream with few lost bytes, and I get this effect.

[fabitom]

@ewbarnes53 did you add build_flags = -D PIO_FRAMEWORK_ARDUINO_LWIP2_HIGHER_BANDWIDTH ? please look at RingBufferDemo.cpp https://github.com/baldram/ESP_VS1053_Library/pull/54/commits

[ewbarnes53]

I saw this, but did not understand what it was, or how it worked, so I removed it. I am using the ESP32 from Adafruit, so I don't know if any changes are needed. Sorry. I do not have a clue here.

Suddenly, a couple of nights ago, my Web Radio Player started working. For most stations now, the worst I am seeing is occasional drop outs. One channel has watery sounding audio still.

Update: Ok, now I see some references to platformIO. I don't think I am going to install and learn a new tool. Sorry about that.

[fabitom]

@ewbarnes53 nwm, that option is for esp8266. But my pull request can help with proper buffering stream.

[baldram]

@ewbarnes53 Would you willing to test this RingBufferDemo.cpp whether it works any better with your stations?
I see @fabitom did this example great for both ESP8266 and ESP32 boards. So without any additional effort, it should simply run with your set up.

[ewbarnes53]

I am now running the RingBufferDemo sketch. I am connected to a 320 kbps station. It seems to be working very well. The print statement doesn't tell me much. It always prints 0.

[fabitom]

I am now running the RingBufferDemo sketch. I am connected to a 320 kbps station. It seems to be working very well. The print statement doesn't tell me much. It always prints 0.

hm... you should see 0-100%, its percent of used buffer space. 100% means full buffer with ready data to play. But in your case it can be problem with display terminal, at 320kbps with 0 buffer you should hear problems with audio. I will check again my demo.

[ewbarnes53]

How strange. The only change I made was moving from one room to another (my amplified speakers are in a different room). Anyhow... most of the time it is now showing 100%. Once in a while, I see it change to a different value, but the audio sounds fine. I have tried playing both my 320 kbps stream, and the one you were using.

[baldram]

the audio sounds fine

@ewbarnes53
That's good news! Does it mean that stations making issues earlier are now okay?

to my ear, it sounds much better. My wife is a trained professional musician, and she reported that it sounded worse than the original, non-chunked radio

Did it also help to get rid of this other issue now?

[baldram]

Ping @ewbarnes53 ;-)