Hi,
We're trying to let minimad play a buffered mp3 on an embedded arm processor. We're using an 8KB buffer (array of chars), which we are filling in the input callback function.
As read somewhere else in the newsgroups you have to start every "new" buffer with stream->next_frame till stream->bufend to prevent a lot of sync errors. We've tried this, but without luck so far. Maybe someone here sees a glitch. (code is at end of message).
On top of that we got a lot of various decoding errors ALWAYS in the last half of our buffer. Even if we increase/decrease the size of the buffer, there are always a lot of errors in the last half of the buffer. We solved this simply by making stream->length as long as half of the buffer, but it's quite a waste of precious cycles to fill the entire buffer everytime when you decode only half of it :s
Hoping for some suggestions,
Tiemen Schut
This is the code for the input callback function:
static enum mad_flow input(void *data, struct mad_stream *stream) { struct buffer *buffer = data; int byte;
buffer->length = 0;
// make sure the last frame is included in new buffer int pos = 0;
if (stream->next_frame != 0 && stream->next_frame != stream->bufend) { while (stream->next_frame + pos != stream->bufend) { todecode[pos] = *(stream->next_frame + pos); pos++; } todecode[pos] = *stream->bufend;
} getnextcluster (&bestand, f); byte = cluster2byte (bestand.curcluster, f); readblock(byte, 4096, &todecode[pos]); bestand.curcluster = bestand.nextcluster;
getnextcluster (&bestand, f); byte = cluster2byte (bestand.curcluster, f); readblock(byte, 4096, &todecode[pos + 4096]); bestand.curcluster = bestand.nextcluster;
buffer->length = BUFFERSIZE / 2; buffer->start = &todecode[0];
mad_stream_buffer(stream, buffer->start, buffer->length);
return MAD_FLOW_CONTINUE; }
We're reading data from a SD-card, hence the cluster-stuff...
On Nov 30, 2005, at 5:07 AM, Tiemen Schut wrote:
We're trying to let minimad play a buffered mp3 on an embedded arm processor. We're using an 8KB buffer (array of chars), which we are filling in the input callback function.
As read somewhere else in the newsgroups you have to start every "new" buffer with stream->next_frame till stream->bufend to prevent a lot of sync errors. We've tried this, but without luck so far. Maybe someone here sees a glitch. (code is at end of message).
On top of that we got a lot of various decoding errors ALWAYS in the last half of our buffer. Even if we increase/decrease the size of the buffer, there are always a lot of errors in the last half of the buffer. We solved this simply by making stream->length as long as half of the buffer, but it's quite a waste of precious cycles to fill the entire buffer everytime when you decode only half of it :s
Reading the code, you seem to be appending 8K to the buffer regardless of the size of the unconsumed portion (denoted by pos) and then telling libmad that the buffer's length is BUFFERSIZE / 2.
I think you need to tell libmad the length is pos + 8192, although it's likely this isn't what you want either, and you'll need to work out another way to fill the buffer up to (but not beyond) its capacity.
BTW, you shouldn't dereference stream->bufend.
-
Rob Leslie -
Tiemen Schut