38 replies to this topic

[legtod2]

I remember my days using mythtv and the issues of syncing video and audio together.

Streaming video and audio can be complicated.

Now if I apply the same principle to pinmame for a DMD display of frames and syncing that with audio that is quite the concept.

I am not sure how much sync is in place for the DMD animation of rom frames to sound samples.

 

When I code my own games using just an arduino or teensy, I give no thought to these concerns.

I stream a DMD gif (Sort of like request gif dmd playback) or I stream a wav/mp3 sound stream but never do I sync the two streams.

As well | would build my own individual DMD frames on the teensy for score and dynamic stuff.

This way I keep my coding logic simple. Kinda like this psuedo code

 

main_line() {

  if (sound_event_triggered) Send_soundnum_to_pi_to_playback();

  if (DMD_Updated) Send_dmd_update_to_teeny(data_frame);

  if (SevenSegDisp_Updated) Send_SevenSegDisp_update(data2);

  if (20x4LED_Updated) Send_20x4LED_Update(data3);

  if (LampUpdated) Send_lamp_ardunio_uno(lamparray);

  ... and lot more stuff

}

 

The drawback to that concept is the lack of sync between DMD and audio

The teensy will have a complete copy of all the DMD frames because it has a local sd card with sufficent store and some local dmd smarts

The pi will have the complete copy of all the wave/mp3 files for local playback, buffering, queuing, multi channels, etc.

The lamp stuff is simply controlled on my little uno. I have to create my own sequencing of lamp control and attract mode sequences.

 

 

This type of methodology works well for my simple games

 

Trying to reverse engineer the rom to a real pinball machine link the lisy1 and lisy80... Thanks pretty cool.

 

Will I ever build and adopt a full pinmame to hardware abstract layer to arduinos and pi for my next project... Time will tell.

 

Normally I want to modify and add my own touches to a game, like adding new rule, skill shots, sound changes, add a DMD to a machine that traditionally had none.

With that in mind, that would preclude me from using a rom.

Edited by legtod2, 12 May 2019 - 01:33 PM.

[legtod2]

More notes:

 

I have compiled pinmame from Ubuntu 18.04 on a virtualized machine and did a compile from my standalone Ubuntu 16.04 machine.

The sound quality sucks on my standalone machine but on my virtualized Ubuntu machine it sounds better.

 

Issues I encounter on the standalone machine was I could not use alsa on the standalone Ubuntu 16.04 but I could use sdl for sound.

 

When I launched from command line

/usr/local/bin/xpinmame.x11 -dp alsa -timer cftbl_l4

 

I have yet to compile on my raspberry pi 3 and trial the same results.

[legtod2]

I have pinmame compiled on the raspberry pi 3 and running.

 

The result of my testing:

 

The FPS is running at 9 - 15 FPS, that terrible and I was expecting at least 30 FPS. I have no idea why its so bad at the moment.

I pressed the F11 key and watch the FPS rate dropping while I was testing.

 

The sound quality is that of a slow rpm record. Imagine yourself talking extremely slowly and you get the idea.

 

I tried using the -sf 44100 and -sf 22050 and no difference still slow talking outcome.

[legtod2]

My virtual machine running ubuntu 18.04 is running pinmame perfectly.

 

The sound is good, the FPS is 60.

 

I gave the Virtual machine 8gb memory and 4 cpus.

 

Guess I could lower both memory and cpu's till I find what is the minimum memory and cpu required but the good news is my ubuntu VM is running pinmame as well as my windows7 pinball cabinet.

 

During my experimenting on my VM, when I tried to use the default sound my FPS was between 8 - 12 FPS, when I switched to ALSA is was a solid 60 FPS and perfect audio and video.

 

The optimal command line to get the best sound and FPS...

xpinmame.x11 -dp alsa -timer cftbl_l4

 

Note: after digging into the help I discovered I could set the default value of the audio timer  and audio plugin in the config file xpinmame-x11rc.

This allows me to omit passing the extra command line parameters (-timer/-notimer or the -dp alsa)

 

timer                   1

dsp-plugin            alsa

 

With that change my command line to start is

xpinmame.x11 cftbl_l4

Edited by legtod2, 25 May 2019 - 09:25 AM.

[legtod2]

Ok, I spent too much time on the sound problem and now its time to move on to the hardware abstract layer.

 

This is where keyboard inputs for flippers, coin mech, sound volume and other events will come from the hardware abstract layer and this is where the switch events that fire solenoids ...

 

Pinmame already has the LISY_X compile pieces in place that talks to a daughter board for controlling a gottlieb first generation and second generation board.

It effectively translates and instructions the daughter board to instruct the lampdriver, solenoid driver, etc.

 

For me, that layer will not be talking to the daughter board, but rather an arduino or teensy.

That conversation will be messages such as turn on/off lamp #, pulse solenoid #, coin insert event, tilt event, etc.

[dmd]

I created an account so I can respond. I am interested in running pinmame on Ubuntu 18.04 because of some hacking I was doing.

 

I found that the pinmame project seems to have already picked up your suggestions. Obviously there are some pretty bad linux problems in the code since it hasn't been kept up to date for Linux. Getting sound to work on a Raspberry Pi could be a big challenge because the audio support is a bit strange.

 

I am interested in either dumping the DMD frames to a file or rendering the DMD straight to a DMD panel from a Raspberry Pi with a this library: https://github.com/h...-rgb-led-matrix  I am just messing around but would like to create a DMD style clock with a Raspberry Pi instead of the typical STM32 microcontroller.

[legtod2]

Neophyte

The dumping of dmd frames is available from window pinmame and pinmame.dll.

In the Linux src, the code is not there. Mike or Thatonedude on pinside.com experimented with pinmame code on the raspberry pi to display roms to a dmd.

For me I wanted to dump frames for gif file creations for my teensy topper project. You can see my progress on pinside.com.

https://pinside.com/.../2#post-4944597

My trial of Ubuntu and raspberry pi proves the pinmame has not really kept pace with source code updates as compared to windows.
The home brew pinball market is starting to help bring interest to updating the code.

Edited by legtod2, 01 June 2019 - 10:57 AM.

[dmd]

Last night I got the basics of the AVICAPTURE code working for linux, Now I can write the DMD out to a video file.

 

This uses ffmpeg libraries so it shouldn't be hard to support various formats, like storing every frame as an image vs an MPEG-2 video. The next challenge is identifying what to capture, I was hoping to do it somewhat automatically.

 

Here is my hack so far: https://github.com/b...me/tree/dmddump

 

Last year I got an esp32 to drive my panels and could do a few things but decided that the resource constraints where going to make it hard to scale. So I bought an adapter for $5 so a raspberry pi can drive the panels directly. It is a lot easier to do it this way.

[legtod2]

Interesting. How are you toggling start and stop. I saw the AVICAPTURE but never saw the toggle or key start and stop for it.

[dmd]

You rebuild it with that defined and it just records everything displayed in the window. If you run with dmd_only set then you will record small video image. I can upload a TZ and a TOM example if you want to see what it produces.

[dmd]

I uploaded my test videos.

 

TOM: https://youtu.be/mf1YDAS4p5s

TOM DMD only: https://youtu.be/TipMdpZVwxQ

 

TZ: https://youtu.be/ZVzimplJXpo

 

When you run pinmame it saves the audio and the video in separate files. The audio files work as well, I guess I can't attach files yet.

 

[legtod2]

I was missing a few packages for the avi/ffmpeg 

• libavutil-dev
• libavcodec-dev
• libswscale-dev

• libavformat-dev

• libdispatch-dev

xpinmame.obj/unix.x11/video-drivers/x11-avi.o: In function `init_dumper':
/pinmame-dmddump/src/unix/video-drivers/x11-avi.c:66: undefined reference to `av_packet_alloc'
collect2: error: ld returned 1 exit status
src/unix/unix.mak:323: recipe for target 'xpinmame.x11' failed
make: *** [xpinmame.x11] Error 1

 

Is the makefile.unix or unix.mak missing some linker refs to libav ?

[dmd]

I was missing a few packages for the avi/ffmpeg 

• libavutil-dev
• libavcodec-dev
• libswscale-dev

• libavformat-dev

• libdispatch-dev

xpinmame.obj/unix.x11/video-drivers/x11-avi.o: In function `init_dumper':
/pinmame-dmddump/src/unix/video-drivers/x11-avi.c:66: undefined reference to `av_packet_alloc'
collect2: error: ld returned 1 exit status
src/unix/unix.mak:323: recipe for target 'xpinmame.x11' failed
make: *** [xpinmame.x11] Error 1

 

Is the makefile.unix or unix.mak missing some linker refs to libav ?

 

Make sure you are on the dmddump branch. I changed the make file to use gcc compiler and different linker options than the original project to fix problems that prevent gdb from running because the wrong libc libraries where linked with vs runtime. Are you building on an 18.04 Ubuntu system?

 

I am now working on getting the compiled code running on a raspberry pi, seems that there are more problems to resolve.

[dmd]

I made a "pi-build" branch which compiles and runs on my Pi 3 B+ and the sound it normal. At my first attempt it was terrible and after wasting a bunch of time I realized that I never converted the full makefile.unix over for the Raspberry Pi and even worse I was using it with optimizations disabled and debugging turned on.

 

After getting rid of debugging, and ultimately taking the compiler flags used by RetroPi it now runs at the full 60fps and the audio sounds normal.

 

If your sound is studdering and popping you can use the function keys to skip frames to speed up the frame rate. When I did this it cleared up the audio, actually I could then tell that it was playing to slow and it sped up. That is when I went back and enabled all the optimizations.

[legtod2]

Yes the pi compile out of the box generated code that ran at 7-12 FPS and sound was in slow-mode.

 

I did not try your branch on the pi. Did you upload your optimizations to the branch ?

 

For the AVI stuff did you start with ffmpeg and then download all of the libraries ? I still can not get ubuntu to compile the AVICAPTURE stuff.

It is still complaining with av_packet_alloc undefined even with the libraries.

[legtod2]

I tried your branch on Ubuntu 16.04 and Ubuntu 18.04 (Virtualized Machine).

 

The branch compiled flawlessly on the Ubuntu 18.04 and ran perfectly, and sounded great.

 

The 16.04 code would not compile the AVI peices, kept getting the undefined reference to av_packet_alloc.

 

I am going to circle back to my pi and try the compile there and check the sound and fps.

[legtod2]

If you really wanted to optimize, you could check out the retropie style of compile for mame and pick and choose your optimization...

 

For example here is version mame0189. The Raspberry pi portion of the compile adds in all the goodies, just check out the makefile and refer to the Rpi references.

wget https://github.com/m...9/mame0189s.zip --no-check-certificate

 

Oh yah, one more thing. You might want to add a toggle to turn on/off the avi recordings.

 

If you look deeper, you can see where mame now has -mngwrite, -aviwrite flags for frame capture.

If you want to plagerize that code you can see how they did the capture to video and capture video and audio.

Edited by legtod2, 03 June 2019 - 04:21 PM.

[dmd]

I tried your branch on Ubuntu 16.04 and Ubuntu 18.04 (Virtualized Machine).

 

The branch compiled flawlessly on the Ubuntu 18.04 and ran perfectly, and sounded great.

 

The 16.04 code would not compile the AVI peices, kept getting the undefined reference to av_packet_alloc.

 

I am going to circle back to my pi and try the compile there and check the sound and fps.

 

Yes my code only works for 18.04, seems that the ffmpeg project made some big changes.

 

I pushed my raspberry pi compiler optimizations to the "pi-build" branch. I would have to clean it up and make some switches to handle the code nicely like the RetroPie project. Since I am just hacking on this I am not sure it is worth the effort. 

 

I don't really know where I am going with this project, I would like to see if I can get the Raspberry Pi to run pinmame and the screen output to draw directly on a DMD LED panel. So I my next step is to mash that hzeller project together with pinmame in another branch and see if it can work. 

 

All these mame emulators need to be multi-threaded so they run better, the Pi now has 4 cores but this single threaded stuff is not efficient.

[legtod2]

I decided to abandon the use of -AVICAPTURE and -aviwrite flag options to record the xpinmame.x11 sessions.

 

Instead I am modeling my new approach to pbxrecord where I am just recording a window session of video and audio.

 

Since I am a Linux fan (Ubuntu and Raspberry Pi favorites) I will be using the tool SimpleScreenRecorder.

 

My goal is to record the Video and audio for my homebrew pinball machine and my DMD topper projects.

 

Example record Video & audio frames to 128 x 32 pixels for further manipulations of my own DMD playback sequences.

 

To record my sequences:

 

1) /usr/local/bin/xpinmame.x11 cftbl_l4 -dmd_only

2) Launch SimplyScreenRecorder (record a fixed rectangle of the dmd area to crop out header of window)

     uncheck cursor check box

 3) Click start record

 4) Save recording

 5) Resize the output file to my desired size and output format (I keep 128x32 pixels and in gif format)

     ffmpeg -i test.mkv -vf scale=128:32 test2.mkv

 6) Then convert my new scaled file to gif

     ffmpeg -i test2.mkv test.gif

 

Then to massage the frame I can use https://ezgif.com/optimize to add/delete a series of frames by uploading the gif file

Edited by legtod2, 09 June 2019 - 02:50 PM.