Media Streaming (MP3, etc.)

[miniupnp]

Media streaming for audio is available in the ce_main_app A few things need to be done for making it easily available to users :

For MP3 / OGG / WMA decoding we need a decent FFmpeg version, not the awful libav version available in some debian based distro. I need to build a newer / smaller FFmpeg for Yocto users.  @atarijookie how much "disk" space is available on users Yocto microSD ? Raspbian users, what are the FFmpeg packages available ? (which version)

My STE player https://github.com/miniupnp/AtariST/tree/master/CosmosExMediaPlayer works. I need help to achieve ST play using YM. My experiments only gave awfull quality I guess it is also possible to make a TT/Falcon version

[atarijookie]

For MP3 / OGG / WMA decoding we need a decent FFmpeg version, not the awful libav version available in some debian based distro.

If I remember correctly, on Raspbian I've checked out the sources of ffmpeg, compiled and installed it, but there isn't anything on Yocyo (yet).

how much "disk" space is available on users Yocto microSD ?

If I see it correctly, there's 60 MB free, so I guess using 40 MB would be OK ;)

Filesystem                Size      Used Available Use% Mounted on
/dev/root               139.5M     70.5M     61.8M  53% /
devtmpfs                 92.7M         0     92.7M   0% /dev
tmpfs                    92.8M    148.0K     92.6M   0% /run
tmpfs                    92.8M      1.5M     91.3M   2% /var/volatile

Raspbian users, what are the FFmpeg packages available ? (which version)

I can't check that out now as I don't have RPi with Raspbian around (at work), but as mentioned - the one built from sources should be there...

I need help to achieve ST play using YM.

Maybe it would be good to reuse / take something from some mod player / demo - ggn has a great collection of demo sources somewhere... wait, I got it from one e-mail: https://github.com/ggnkua/Atari_ST_Sources/

[mikrosk]

No need to do that, Jookie. At least as far as MOD players are concerned, my mxPlay uses XMP library which basically plays any module format on the planet. So if I were looking into RPi-based mod player, XMP would be my choice -- multiplatform, supported, easy :).

[atarijookie]

@mikrosk No, you misunderstood me - we need to implement mp3 playback on ST (not STE), that means sample playback through YM, and for that sample playback routine I suggested to take a look at the sources of some existing mod player and use that for the sample playback...

On the other hand - adding that XMP library on RPi for that kind of mod player - cool feature suggestion ;) Once the Media Streaming is done completely (playback on ST, STE, decoding on RPi), adding this one would be easy...

[miniupnp]

I'm building FFmpeg 3.2.2 on my Yocto CE, I'm pretty confident it will be about 10 or 15MB max

[atarijookie]

Wow... Then we just need to upload the binary to the server and create a simple script, which would user need to run to download the thing...

[miniupnp]

here it is. I need someone with a Raspbian RPi ( @tin-nl ? @mikrosk ? ) to build the binary package. Just "make" and wait.

Also anyone with Yocto can test the install_ffmpeg.sh script. (Raspbian is detected but the package is not available yet)

[atarijookie]

@miniupnp Would be ffmpeg 3.0.git enough? It's already included in the Raspbian image - I've built it like 2 months ago so it would be already there :)

[miniupnp]

hum I don't remember when my patch was integrated uptream. somewhere in 3.0.x So better test my build script :)

[atarijookie]

using your script, which made it easy :+1: https://www.dropbox.com/s/scg3crlcmb5udox/ffmpeg-3.2.2-raspbian-bin.tar.bz2?dl=0

[miniupnp]

So I'm merging. the ffmpeg update script should be integrated into the upgrade process somehow...

[atarijookie]

install script added to instalation - has to be triggered manually by user from shell... however there's a small mistake there on Raspbian:

/ce/install_ffmpeg.sh: 21: [: 3.2.2: unexpected operator
--2016-12-29 11:18:16--  http://nanard.free.fr/CosmosEx/ffmpeg-3.2.2-raspbian-bin.tar.bz2

[miniupnp]

fixed ;)

[atarijookie]

Wow, you're fast as a lightning :) I didn't expect differences in shell between yocto and raspbian, but there seems to be more things hidden than I expected... Anyway, good job! :+1:

What about the ST / STE playback app? Is the ST support already done, or should we ask someone for help with the non-STE playback?

[miniupnp]

As said before the sound is awful but I will release something so there is a basis to work

[tin-nl]

Also anyone with Yocto can test the install_ffmpeg.sh script. (Raspbian is detected but the package is not available yet)

@miniupnp: Do you still need this test?

[tin-nl]

As said before the sound is awful but I will release something so there is a basis to

@miniupnp: Did meddle alot with digi replay back in the days - I can have a look if you want (and I remember anything). But the ST digisound quality is quite awfull unless you use literally all available CPU time.

[miniupnp]

@tin-nl ok so the quality would be bad anyway If ffmpeg is installed to your CosmosEx (which should be the case thanks to the last upgrade) you can test ;) https://github.com/atarijookie/ce-atari/blob/master/ce_main_app/mediastreaming/mediastreaming_commands.h

[miniupnp]

CE "media streaming" commands are sending 8bit signed PCM

[tin-nl]

@miniupnp: Finally came around to testing install_ffmpg.sh on an yocto device - download/depack works, but the binary needs libxcb-shm.so.

On raspbian it works out of the box, cool stuff :)

[atarijookie]

On raspbian it works out of the box, cool stuff :)

Do we already have that Atari player for non-STE machines? I'm using my CE with STFM mostly, and I would like to try the playback, include the player in the next release and make a short video about it :) (or miniupnp can do it, if he wants to be the one who makes that video).

[tin-nl]

Haven't seen ST replay in the CEMediaPlayer. Main problem there is probably the DMA hogging the bus at transfer time, resulting in delayed replay interrupts. This would have to be carefully timed to reduce jitter and also determines the max replay rate possible. But it's safe to say that 50kHz (although easily possible from RAM) won't work on a bog standard ST with 8MHz.

[atarijookie]

But it's safe to say that 50kHz (although easily possible from RAM) won't work on a bog standard ST with 8MHz.

I wouldn't go up to 50 kHz anyway, I would just stick to 16 kHz, mono, 8 bits / sample - that one could work, right? :) I think people will accept that without HW playback the quality won't be the best.

[tin-nl]

Should work, yes. But even for 16 kHz (which is roughly 1 sample per scanline in 50Hz) there's only a ~400cc window where the ACSI transfer has to occur to not delay anything. So it has to be timed carefully either way.

[miniupnp]

I have to check for this libxcb-shm.so issue. @atarijookie 50KHz is not even possible from RAM ! I've been said you can go up to 20KHz or maybe 24KHz with special techniques (like not saving registers in the interrupt routines) but I've not been able to play reliably at more than 12KHz. And that's without ACSI transfers going on simultaneously... I've been quite busy lately, I'll try to get something together as soon as possible

[atarijookie]

Well then, to write it in general matter - for non-STE machines lets just limit it to whatever lowest sampling rate that works ;)

[tin-nl]

Ah, the underestimation of our old friend the Atari ST - something has to be done there, so pardon my french ;-)

50KHz is not even possible from RAM !

@miniupnp: I sincerely beg to differ. It's almost 30 years since I've coded a sample player from scratch, but IIRC setting the ym to a specific amplitude takes ~100cc per sample (~80cc if you're willing to use word samples). Sure, CPU Time gets cramped via IRQ - 50cc for IRQ+20cc for RTE+saving 2 regs+keeping sample register - it's hard (but probably not impossible) to get the whole IRQ under 160cc - although pointless. But it is trivial w/o IRQs using speedcode on an 8 MHz ST. Wether or not 50kHz is of any benefit due to 8 bit mono is another discussion :)

I've been said you can go up to 20KHz or maybe 24KHz with special techniques (like not saving registers in the interrupt routines)

@miniupnp: That numbers don't sound quite right. I know that our main ST Mod-player rout did play samples at 21kHz max on a bog standard ST - and that's while software mixing 4 channels with full volume control in parallel. Heck, even my Tracker (Mod Editor) did 16kHz even with it's UI active.

but I've not been able to play reliably at more than 12KHz. And that's without ACSI transfers going on simultaneously... I've been quite busy lately, I'll try to get something together as soon as possible

@miniupnp: I couldn't find any ST implementation in your (superb btw) Media player. If you send me sth I can probably do sth about that.

[miniupnp]

@tin-nl https://github.com/miniupnp/AtariST/tree/master/ym_digit http://atari-forum.com/viewtopic.php?f=103&t=29832&start=25

[tin-nl]

@miniupnp: Cool, I'll have a look.

[tin-nl]

A quick test: This is an unchanged AU file from RAM with IRQ, full register recoverage and w/o any dirty tricks. One of the main culprits at higher frequencies for your old player could be the dreaded Timer C (aka 200Hz), which blocks quite some scanlines with 50Hz. Since this is going to be a foreground-player w/o gemdos file-access anyway, we can disable this for STs (it's mainly for keyrepeat and the 200Hz tick). It's probably good to have at least two reference implementations for ST replays: one for ST background replay (aka behaving nice) and another even faster one which blocks the whole system w/o using IRQs and tight, manually crafted ACSI timing. As said before - the ACSI timing is my main concern, I measured a lot with FDC DMA timing back in the days, but not with HD DMA.

Another thing I had a quick look at: I think the mathematical model of the volume table generator included in your test could be a bit optimistic. This is just a hunch atm, have to investigate deeper. Here I plotted the value propagation of the ym output for all ABC combinations (0-65356, as measured by Paulo Simoes): You see it's probably best to use only the lower half/two third of the output level, as we get alot of errors in the top part due to missing values. I did add an brute force search through this measurements to the table generator, but I still have to compare the error of both approaches. Due to laptop speakers I cant compare by ear atm.

I hope to get a first prototype finished and cleaned up this week.

[miniupnp]

thanks !

[miniupnp]

about the libxcb-shm issue, here us what I've got obn my "development" yocto image :

root@raspberrypi:/usr/local/bin# ldd ffmpeg 
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x48a88000)
        libxcb-shm.so.0 => /usr/lib/libxcb-shm.so.0 (0x48cd0000)
        libxcb-xfixes.so.0 => /usr/lib/libxcb-xfixes.so.0 (0xb6f60000)
        libxcb-shape.so.0 => /usr/lib/libxcb-shape.so.0 (0xb6f56000)
        libm.so.6 => /lib/libm.so.6 (0x48530000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x48500000)
        libbz2.so.0 => /usr/lib/libbz2.so.0 (0x48618000)
        libz.so.1 => /lib/libz.so.1 (0xb6f3b000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x484d8000)
        libc.so.6 => /lib/libc.so.6 (0x48398000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x48aa8000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x48ab8000)
        /lib/ld-linux.so.3 (0x48368000)

can you tell me what's ls -l /usr/lib/libxcb* ? it looks like theses library are present in the developement image, but not the "user" one...

[miniupnp]

@tin-nl I have recompiled without need for Xlib or libxcb http://nanard.free.fr/CosmosEx/ffmpeg-3.2.2-poky-yocto-bin.tar.bz2 It looks better :

# ldd /usr/local/bin/ffmpeg 
        libm.so.6 => /lib/libm.so.6 (0x48530000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x48500000)
        libbz2.so.0 => /usr/lib/libbz2.so.0 (0x48618000)
        libz.so.1 => /lib/libz.so.1 (0xb6f12000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x484d8000)
        libc.so.6 => /lib/libc.so.6 (0x48398000)
        /lib/ld-linux.so.3 (0x48368000)

[tin-nl]

@miniupnp: Perfect, thanks alot! install_ffmpeg.sh does work now, player does to, tested two different yocto devices (both with non-dev yocto).

Nice one :-)

Now back to ST replay, I don't need/want no custom chips ;-)

[tin-nl]

Quick update with a small progress: Yellow graph is the math approach (aka the ym specs are lying) and white the table generated from Paulo Simoes measurements. Both are a 0-255 sawtooth played through the ym via the respective dac table. I also have re-measured the three channels volume propagation, but still have to check if my data will lend to better results than Paulos - slim chance, but we'll see.

[tin-nl]

@atarijookie: When you were building your endless stream of ACSI devices: did you at any point try to get ACSI PIO running (e.g. for data in). I got it working somewhat, but wanted to make sure there's nothing known on the CEs side to prevent it before I investigate further.

[atarijookie]

did you at any point try to get ACSI PIO running (e.g. for data in).

No. The usual flow for fast data transfers is:

• command: 6 to 11 bytes - PIO OUT
• data: large blocks (multiple of 16, when transfering sectors then multiple of 512) of DMA IN / OUT
• status: single byte - PIO IN

I'm not sure if data transfer is doable in PIO mode - maybe it is. I never tried as I needed to achieve highest possible speed, and that PIO would slow it down (compared to DMA).

If it's possible, it shouldn't be a problem, as long as the data part is synchronized using the DRQ/ACK signals on ACSI port - the device doesn't care if it's the CPU or the DMA who toggles them in data phase, but it has to be these two wires in data phase.

In PIO (command and status) the data is synchronized using INT/CS signals.

[tin-nl]

No. The usual flow for fast data transfers is:

I know :)

I got pio running (or at least sth that looks like pio), but ran into some caveats: a) it's more like snooping the ACSI bus - seems like DRQ runs at DMA speed (and DMA is not writing to memory) so it's not quite usable for most purposes b) the data register introduces waitstates. Didn't measure exactly yet, but while reading from the register the loop takes <> the 160k cycles it should take. Not shure if it's more or less cycles, but it's all OK when reading from another (non-register) location. This happens when DRQ is disabled (12cc read takes 16cc) and it's also different when DRQ is enabled. It's is possible DMA steals bus time, although it is not writing data to into RAM.

Overall I did not investigate very deep, but I hope to look at it this WE (and finish the promised cleanup first).

[miniupnp]

@tin-nl where can I get a table generated from Paulo Simoes measurements ?

[tin-nl]

@miniupnp: as said above - from the brute force search added to the table generator :) See attached. Note that for now I only measured the l33121.s (see graph above) not the calculated "optimal" one (l28806.s). I think there is still room for improvement re accuracy of YM DAC, but I'll first tidy up the replays before I get on with that.

ymtable.zip

[tin-nl]

@miniupnp: here's the optimized YM DAC routine. I included it in your AU player, see attached (only changed/added files).

It is TOS compatible (saves registers and doesn't need autointerrupt) and plays up to 31kHz without dirty tricks. Having said that: it needs a 64k-aligned playbuffer (64k in size) and a 64k-aligned code buffer (again 64k in size) . There's a slow 26kHz timer in there, too, just for reference.

Now I'm off to the hard part - synchronizing the replay with ACSI access... ym_digit_optimized.zip

[miniupnp]

nice !

[tin-nl]

Some new findings on the PIO front - unsynchronized PIO is possible indeed, But: lossy. Since DRQ/ACK seems to be driven only by DMA, there are two options: doing PIO completely synchronized to DMA/CE speed (unusable IMHO) or starting the DMA, snooping the ACSI bus and stopping the DMA again. With the latter I read only every 4th byte (varies a bit), but after that I can wait as long as I want (and hans' timout permits) before reading the next byte. It seems indeed possible to play samples as fast as the ST can and get data from ACSI at that speed. This is very early stages, but it really seems worth a try.

Regarding waitstates: fortunately the timing with the start/stop approach is stable and the CPU doesn't seem to be delayed by ACSI speed while reading the data register. Only connecting the data register to the FDC introduces 4cc waitstates (move.w (A0),(A1)+ takes 16 instead of 12 cc with A0=ff8604).

So speedcode for playing the sample remains trivial - but synchronizing with the DMA/CE data stream probably isn't - we'll see. But it might be possible :)