The one suspect thing is using two conditions in the byte send loop (i < 48 && buffer->space < 1024). 48 tells me you have a 48*32 = 1536-byte buffer, which is 3 disk blocks. What does buffer->space contain? Can the loop be exited early in some cases?

buffer is a queue (first-in-first-out) with the size of (32 Byte * 1024 =) 32 KByte. This queue is filled by data received from Wifi-/HTTP-Connection.
Internal my queue is a simple one-dimension-array.
buffer->read() returns a pointer to the current reading-position.
buffer->write() returns a pointer to the current writing-position.
To reduce the overhead of each function call the queue is seperated in (logical!) parts of 32 Bytes, so every read-call reads 32 Bytes.
My HTTP-receive-function writes directly 32 Bytes into the queue using buffer->write(), so I do not need to copy memory.

uint8_t data_block[this->chunkSize * this->amount]; //32 * 1024
//public reading access
uint8_t *RingBuffer::read() {
space++; //Now more space is available. space is public accessable and was set at the beginning to 1024 by constructor
return this->get(&this->index_read);
}
//public writing access
uint8_t *RingBuffer::write() {
space--; //Now less space is available
return this->get(&this->index_write);
}
//private internal function
uint8_t *RingBuffer::get(uint16_t *index) { //this->chunkSize is set to 32
uint8_t *buf = &this->data_block[((*index) * this->chunkSize)]; //get a pointer to an array field
(*index)++; //increase the writing/reading index
if(*index == this->amount) { //jump back to the first index, when the buffer is full (ringbuffer)
*index = 0; //this->amount is set to 1024
}
return buf;
}

However, the loop (i < 48 && buffer->space < 1024) reads now 32 Byte in each iteration and sends them using playChunk(..).
The loop runs 48-times, but only as long as we have current data in queue - that is necessary to prevent reading old data from the queue.
So 1536 Bytes are send each time, normaly. The queue is filled regulary with new data, so normaly it works good.

Is there any container in the http-receive protocol that needs to be stripped?

I strip the HTTP-Reponse-Headers (200 OK HTTP/1.1, Content-Length and so on including the last "\r\n\r\n") nothing more.
Wenn I download the file on my PC, I can play it well. So I do not think I need to strip more.

because whether delayMicroseconds(1) is enough depends on the SPI speed. It would be better to wait until the transmitter is idle, but for a quick test, just increase the amount of microseconds to see if it makes a difference or not.

Maybe try these to see if it makes any difference...

I strip the HTTP-Reponse-Headers (200 OK HTTP/1.1, Content-Length and so on including the last "\r\n\r\n") nothing more.

So there isn't any Icy-Metadata (Icy-MetaInt) in the header - it's just a raw binary file?

I thought client->read(..) would write always 32 Bytes, of course it does not . 32 Bytes specified the upper border, the maximum size of the buffer. But not the amount of Bytes I want to receive.
So client->read(..) returned sometimes less than 32 Bytes, this causes the buffer to contain zeros or if the buffer has already been filled to contain old data.