Can MP3 cards play music in background?

Page 1/2
| 2

By DarkSchneider

Paladin (1021)

DarkSchneider's picture

04-12-2019, 11:32

I wonder if MSX MP3 card devices can play MP3 music in background by its own working as co-processor. I know about the MP3 card and that the GR8NET can be flashed as one. Don't have any so maybe someone could solve my question.

Login or register to post comments

By edoz

Prophet (2482)

edoz's picture

04-12-2019, 11:44

At least SymbOS can do it because of it's multitasking. But only the sunrise compatible MP3 cards are supported.

By Parn

Paladin (837)

Parn's picture

04-12-2019, 14:37

GR8NET can probably do it, but not if you use the _NETPLAYWAV command. This keeps playing the MP3 until you press ESC. Per the technical manual, I think it would be possible to use the video interrupt to keep the buffers full in the background. The downside is that you would have to program it and you'd probably have to keep the entire MP3 file in memory, which wouldn't be too practical.

By DarkSchneider

Paladin (1021)

DarkSchneider's picture

04-12-2019, 19:18

Indeed. I was thinking more about the device reading the MP3 by its own.

By Grauw

Ascended (10772)

Grauw's picture

04-12-2019, 19:26

I see no reason why it couldn’t install a TSR which reads from disk, but of course it will slow the computer down and not all software will like a TSR, or a TSR which takes the CPU to do disk access every so often. The biggest hurdle would be that someone has to make it.

By marcoo

Expert (111)

marcoo's picture

04-12-2019, 21:48

the se-one is a great MP3 cartridge and plays from a USB stick on its own

By DarkSchneider

Paladin (1021)

DarkSchneider's picture

05-12-2019, 09:14

Grauw wrote:

I see no reason why it couldn’t install a TSR which reads from disk, but of course it will slow the computer down and not all software will like a TSR, or a TSR which takes the CPU to do disk access every so often. The biggest hurdle would be that someone has to make it.

Is that reliable? I mean, the disk access is disk-rom (AKA disk controller) related, so it would depend about the implementation. I.e. if I read X bytes from disk per interrupt, is it guaranteed to not use more time than required, consuming the whole interrupt time or even more while the disk stops (when the LED turns off)? In other words, is real-time streaming possible from a device like HDD or SD card, taking a fixed ammount of CPU (depends of bytes read) per V-period (VBlank to VBlank time)?

By Grauw

Ascended (10772)

Grauw's picture

05-12-2019, 11:28

Any MP3 player requires the disk interface to be fast enough to be able to provide it with data, even for standalone playback. It will have a circular or double buffer, but it will likely be a few kB in size and won’t be large enough to fit an entire MP3. So it relies on the MSX to pump data to it before it runs empty. It must work like this since any MP3 is easily several megabytes in size and that much memory is not typical for MSX-es.

Of course it will likely consume a good chunk of CPU, probably several interrupts worth, but that’s not a problem in principle, just everything outside the TSR will run slower. And if the disk somehow stops it will glitch of course, though you can of course also have an additional memory buffer in the MSX large enough to absorb such an event if the MP3 cart’s internal buffer isn’t large enough. I think normally that wouldn’t happen with the SD interfaces and such we have nowadays anyways.

I don’t think you can count on a fixed amount of vsynced time. Streaming from disk out of principle will be unreliable timing-wise given the various amounts of disk interfaces out there. And of course floppy disks are out of the question, they are most definitely too slow. Run a disk speed testing tool, the transfer speed should be greater than the bitrate of the MP3 for it to work.

But just look at SymbOS videos on Youtube about what’s possible in principle. There’s several demos using the MP3 player in parallel with other tasks.

By DarkSchneider

Paladin (1021)

DarkSchneider's picture

05-12-2019, 12:01

Grauw wrote:

I don’t think you can count on a fixed amount of vsynced time. Streaming from disk out of principle will be unreliable timing-wise given the various amounts of disk interfaces out there

That's my main worry. The standard does not define (reasonable) disk behavior, so you could get smooth reading from one device and chunky reads from another. It is not the same than counting with DMA devices assuring a certain ammount of transfer speed by specification.

I am doing numbers and seems to be out of possibility. For a typical 128Kbps have to transfer 273 bytes to the device per vsync, plus reading the same ammount from disk (that is even slower), for real-time I see it not usable.

By Eugeny_Brychkov

Paragon (1232)

Eugeny_Brychkov's picture

12-12-2019, 10:13

It is possible to program with GR8NET, but there're several things must be sorted out beforehand:
1. access sharing. If MP3 player will use SD-card for background playback, then there must be a mechanism to ensure there is no conflict between it and, for example, Nextor accessing the SD-card. Same for network - it will occupy one of the sockets, which then will not be available for BASIC and other applications.
2. buffering. While not that critical when playing from SD-card, it is critical when accessing network. MP3 player is currently using 128KB buffer size inside the GR8NET. This means this space will not be available for user/applications any more.
3. data source selection. How player, in background, will select file to play? Must it be provided with the list of the files (where to store it then?) or it is provided directory name and then plays all files from it in some pattern? In case of network it is not applicable.

Is this feature is generally useful? You can have another MSX nearby playing MP3 (even without monitor connected), or any of your contemporary gadgets doing it.

By DarkSchneider

Paladin (1021)

DarkSchneider's picture

12-12-2019, 12:43

The idea is to improve music capabilities for programs (real-time), so the authors also have more freedom to use their favorite tracker (even on PC or Mac).

I have been getting info about it, and seems something Arduino based could be cheap, but it would require to make a new device. Fortunately a device like this one could be used by everyone as I think it could be very useful.

Here some info (in spanish) about the module:
https://www.luisllamas.es/arduino-mp3-dfplayer-mini/
http://www.playbyte.es/electronica/arduino/dfplayer-mini-mp3/
https://youtu.be/WbrP9TyMr9E
It costs only about 1.20€, and I think it would not be much difficult to handle it connected to slot pins.

Page 1/2
| 2