General Category > LisaList2
LisaEm 1.2.7-RC4 support bug reports
rayarachelian:
2022.04.01 - pushed to unstable + master branches. https://github.com/rayarachelian/lisaem/tree/unstable
Windows Packages:
* https://sunder.net/downloads/LisaEm-1.2.7-RC4-2022.04.01-win-x86_64.exe
* https://sunder.net/downloads/LisaEm-1.2.7-RC4-2022.04.01-win-x86_64.zip
Skinny Packages:
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC4-2022.04.01-macos-10.10-x86_64.pkg
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC4-2022.04.01-macos-10.11-x86_64.pkg
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC4-2022.04.01-macos-10.12-x86_64.pkg
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC4-2022.04.01-macos-10.15-x86_64.pkg
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC4-2022.04.01-macos-10.5-i386.pkg
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC4-2022.04.01-macos-10.5-ppc.pkg
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC4-2022.04.01-macos-10.7-x86_64.pkg
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC4-2022.04.01-macos-10.8-x86_64.pkg
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC4-2022.04.01-macos-11.0-arm64.pkg
* https://lisaem.sunder.net/downloads/lisaem-1.2.7-RC4-2022.04.01-macos-11.0-x86_64.pkg Full macos package:
* https://lisaem.sunder.net/downloads/LisaEm_1.2.7-RC4_2022.04.01-macosx.dmg
rayarachelian:
Recently, Ubuntu had a new LTS, 22.04, which switches the sound system to PipeWire. This is in the long term a good thing, however, previous versions used pulseaudio, and before that OSS, and before that ALSA.
With PulseAudio, an OSS proxy package was provided that allowed applications that used OSS's dev tree muxes/dsp end points to allow applications expecting them to work on PulseAudio.
Unfortunately there's some issue/bug/other with the current 22.04 release. After installing OSSPD (the proxy package), I've noticed that the sound implementation in wxWidgets will lock up a mutex permanently when a wave file is being played in a loop. Unfortunately this is the method I use to generate sound on LisaEm.
So the effect is that whenever the Lisa plays a sound, LisaEm will permanently lock up.
A bunch of this is related to wxWidgets not supporting anything else, and on GTK requiring SDL for wave playback. There's a note that says wxWidgets requires SDL for this, which is less than ideal as it requires me to link in yet another library that's not quite large, but misused as SDL also does graphics and other things that are unused.
Sound seems to be a second class citizen in wxWidgets currently, and for backwards compatibility this is also an issue. All it can do is play a single wave file at a time, optionally asynchronously, and optionally looping the same sound. If another sound play call is issued the current sound stops playing. This works ok for windows and macos without SDL (I think), but never for GTK+ (Linux, *BSD, *Solaris). There were some discussions in the wxWidgets forums about this, but nothing has been implemented. So I'm leaning either for a workaround, or a replacement.
Unfortunately since my current daily driver development machine runs Linux this is a blocker.
Since I'm getting ready for a prod release, this is a problem as it requires a new, mostly untested, solution.
There's what I'm looking at as strategies:
* change the wave file size I'm using to several seconds instead of using looping - this would require more memory use and a work around, but it might work, haven't tested to see if I can stop the sound early successfully if it's something like 5-10 seconds of a wave file.
* directly talk to SDL and see if I can produce working sound that way.
* switch to OpenAL or SoundVox, and a few others - of the two, OpenAL is the smallest and most widely compatible - leaning to this as well. There's a small snag here, OpenAL is no longer provided for modern macos, however it does still compile there, and can run fine. No telling if it will still work in the future, but it's no different than X11 or OpenGL support. As part of Apple's war on all things GPL (including bash, and gcc) and closing off source code they've removed this as well in favor of proprietary frameworks.
* directly targeting the PipeWire calls is not an option, as I'd like to avoid writing platform specific code as much as possible and worse, elder Linux and other OS's that may use ALSA, pulseaudio, OSS, JACK, etc. would then also need yet another exception to work.
Ideally I need something that can play multiple wave files in the background (floppy, widget, imagewriter, etc), but also optionally constantly play sound data preferably without having to create a wave file either in RAM or on disk and then calling the play function. Something like a circular buffer that I can feed new values from the shift register of the VIA to generate sound - like a mixer or the way classic macos does.
The sound output of the VIA is just 1 bit, so it's an 8 cycle (8 bits in SR) timed square wave pattern at a specific volume so perhaps a synth output would be a good shortcut so I don't have to manually generate a large repeating buffer in memory with it.
rayarachelian:
--- Quote ---* change the wave file size I'm using to several seconds instead of using looping - this would require more memory use and a work around, but it might work, haven't tested to see if I can stop the sound early successfully if it's something like 5-10 seconds of a wave file.
--- End quote ---
Nope, this doesn't work. I set the wav file to 10s, but when Sound.Stop() is called, it locks up on the mutex the same as LOOPING audio, so the real issue is with the Stop and not the LOOP.
rayarachelian:
So, RC4 has some bugs on MacOS and Windows in regards to hard drive/floppy images, likely I screwed up something in libdc42. see: https://github.com/rayarachelian/lisaem/issues for the bug reports.
I might have fixed that, not sure as I've not tested on Windows/macos yet, but also haven't pushed to github yet. Will do so. I'm considering a rewrite of libdc42 to add new features that were meant for 1.2.8 that will be necessary.
I'm currently finishing off the move to the OpenAL (Open Audio Library) from wxSound. LisaEm will continue to use wxSound if OpenAL is not installed on the system it's compiled on. Note that Apple in its war against GPLed software, and things like OpenGL has removed it from recent macos versions, though it's possible to compile it there anyway.
This will be released as RC5 once tested, etc.
greniu:
I have tried to install it on fresh Windows 10, macOS Catalina 10.15 and always when trying to boot from a floppy drive I am receiving this error:
"Sorry, the emulation aborted due to a fatal error. Have a cow man! ipc=NULLL
Stopped at cpu68k.c:cpu68k_makeipclist:1096 with code: 54
LisaEm will now quit".
It seems that there is a bug in the code. Please help to run LisaEM.
Do you know which version of OS is stable to run LisaEM 1.27-RC4?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version