- Sometimes the sound is interrupted for a short period. Seems to be a bug
in the timer.device that sometimes causes interrupts to be delayed. I
tried very small intervals, but it still remained, so I guess it's either
a bug in timer, or the system interrupt load causes high latencies.
I might elaborate more on these problems. The original MAS Player by Dirk Conrad uses the parallel port to both send I2C commands and serially clocked mp3 data to the MAS-Chip (bitwise!). The first, old version even required two bits to send out one bit of MP3 data. Due to the internal parallel port being custom chipset register space, it is rather slow to access this space (like chipram).
The MAS Chip itself has a buffer of about 1 KB, if I remember it correctly. It has a pin that will report when the buffer is getting full and the sender should stop transmitting data, I think I may send up to ~250 bytes after this pin has changed. Unfortunately, the MAS Player design is a bit flawed in the sense that the change of the buffer full line is not connected to the _ACK pin that would allow interrupt driven data transfer. Instead, I have to constantly track the signal level of this pin before sending more data (I do this every ~250 bytes).
Due to VBR and the internals of this chip, it makes it hard to estimate the rate at which the buffer full line needs to be checked to avoid buffer underflows. I really tried a lot of different techniques, but in the end, I just had to make sure that the line is checked often enough and the current implementation uses a sliding interval that automatically adapts to the rate of the MP3. But this means that the driver causes many interrupts per second, thus requiring some CPU time (that you're unable to measure with Scout and such).
Now, let's look at the MP3@64. This device was designed to be operated in the C64 with Jens' custom build clockport there. Unlike the MAS Player, I can send the serial data bytewise, not bitwise, which would actually be much better, if not... well, the MP3@64 streams the bytewise data to the MAS Chip serially, *just like the MAS Player* and it uses a timing that the C64 is slow enough to write one byte after another without disturbing the serial transfer that is done by the logic in the background.
The Amiga however, is much faster. So while I had to write out the data bitwise to the parallel port on the MAS Player, I can write a full byte in one go, *but then I have to wait for a while* before I can send the next byte. Of course this wait is so short that it doesn't make sense to release the CPU to do something else. Hence, the MP3@64 needs more or less the same CPU time as the MAS Player.
And finally, the MP3@64 also doesn't connect the buffer full line to the interrupt 6 pin of the clockport, hence the polling of the overflow line is also the same there with the same problems described above.
Hence, you will need some CPU time to operate the MP3@64 or MAS Player, and the stutter will be less if you've got a faster CPU. You probably shouldn't be using high frequency interrupt sources like the internal serial port at the same time.
The stutter probably will be gone if somebody rewrites the interrupt code not to use the timer.device (more system conform), but the CIA chips directly. Jens has the code of the device, if I remember it correctly.
