MP3@64 stuttering and skipping

[platon42]

- 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.

[platon42]

MP3's down a 1-bit serial interface? I'm not sure what the Amiga parallel port is capable of, but I would imagine you could pre-process your MP3's into I2C files you can DMA.

For a fixed rate MP3 that could be 192Kbaud, what is the maximum rate of the Amiga parallel port?

There's no DMA to the parallel port or serial port. Check your hardware documentation The only DMA you could try would be audio (which is rather useless, as it's analogue) or disk (which might work, but then again, the data rate is pretty low here).

Moreover, the mp3 data is not sent via I2C. Only the control commands are send via I2C (such as volume control).

On the other hand, something probably hardly anybody knows: One CIA is used for barrel-shifting serial data from the keyboard. The second CIA also has this barrel-shifter (bidirectional) and it is connected to some lines on the parallelport. I'm fairly confident that this parallel to serial converter could have been used in the MAS Player design to speed up things, but unfortunately, it wasn't.

[platon42]

The parallel port itself is able to do it speed-wise for 192kbps files anyway, I don't have any trouble with that here. Possibly something to do with the clever trick the player does in clocking data on the leading and falling edge of the signal, thus saving half the number of pulses...

The trick with the rising and falling edge is exactly the difference between the normal and the later, Pro version of the MAS Player.

[platon42]

Interesting stuff... didnt know there was no DMA to parallel port. Damn that's a bit of an oversight. I am sure there must be a technological reason why not.

Probably because it requires additional logic to conditionally DMA stuff depending on the _ACK handshake signal of the printer connected to the parallel port. I don't think this line (or any other CIA line) is routed back to the DMA engine in the Agnus chip.

[platon42]

Thank you Chris for that good, concise explanation. It seems that there wouldn't be much benefit for me to switch to the MP3@64. Do you know why the interrupt isn't used? Or if it might be possible to modify the MP3@64 or the MAS player to use it? I guess then it would also need a new MHI library...

I am hoping to be able to use the internal serial port with my project, but it can be run at low speed (9.6k should be enough) as it's only used to update an LCD display and maybe receive IR remote codes in the future, so I don't think the interrupt load will be too high. If it is, do you think that could be improved by switching to the MP3@64?

It probably would need some sort of transistor or inverter gate. I haven't looked at the schematics for a long time. The interrupt wasn't used on the MP3@64 as it was specifically designed for the C64 and not for the Amiga.

9600 bits/sec is not a high load for the serial port. 115200 bits/sec surely is (and barely achievable).

[platon42]

Hmm, I thought there was something in Paula that did it. It's been a long time since I looked at this stuff

Assuming there is no hardware MFM, then even better. One less thing to worry about on the device end. You've got a DMA driven serial port that should be able to shift data at a high enough bitrate for a lot of mp3s...

I once wrote a device that would use 2bit -> 3bit encoding but it only worked reliably for the first 40 cylinders. That would have provided >2.5 MB/HD (32 sectors) or >1.2 MB/DD (16 sectors) disk. But I canceled the project because at that time (1998) already the use of floppy disks was dwindling.

The blitter was used to generate the MFM encoding (3 passes for bit splicing and remerging) and decoding (1 pass for merging).

I googled for nearly one hour to find the DMA speed of the floppy controller, but I wasn't successful. The closest estimate I can give is about this one: there are three DMA slots for disk and one slot for each audio channel. While at PAL the maximum replay frequency is about 28 KHz (2 samples per slot), and the disk DMA is supposed to transfer one byte per slot, I get a theoretical maximum speed of about 42 KB/sec for disk DMA.

(As the DMA assignment didn't change even with AGA, this is the reason why Amiga HD drives spin at half speed, because Paula cannot keep up the required data rate.)