LisaList2

Advanced search  

News:

2019.06.07 fixed NChat for the "Curve" theme, will eventually move it to its own page and add it to the default theme as well. Other plugins are next. see post in the Meta board for details

Pages: 1 ... 9 10 [11]   Go Down

Author Topic: LisaEm 1.2.7-RC4 support bug reports  (Read 24981 times)

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +45/-1
  • Offline Offline
  • Posts: 682
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-UNSTABLE support bug reports
« Reply #150 on: January 11, 2022, 11:33:35 am »

Minor update: fixed some of the copy/paste bugs in TerminalWx code, so this helps us on the road to a future where we'll have a mostly usable terminal window for things like UniPlus, and eventually Xenix, and LPW, as well as a built in interface for BLU to connect LisaEm to an actual physical Lisa. Terminal for things like the unixes and LPW would be very useful for me so I can write code without being limited by a bitmap screen and lack of clipboard passing between host and guest. Eventually (maybe 2.0?) the idea is to have the ability to call LisaEm headless and compile things form a host side Makefile, sort of like that modern day MPW package.

Eventually will add preferences for the Terminal window to select terminal size (80x25 for now), font (Courier New), font size (12 for now), colors, etc. (Likely I'll add a preferences notebook page for this in 1.2.8.)

TerminalWx is not full featured, but it's good enough, lacks a lot of features (most notably double click and triple click don't select properly, no scrollback, etc.), but, it's better than nothing. The alternative would be to try to interface with an external program by creating a pty, but that would be problematic with Windows. If there's interest in future releases.

Still need to fix UniPlus installs (sunix kernel v1.1 profile bugs) before RC4. Hopefully by end of this month if all goes well.
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

andrew

  • Newbie
  • *
  • Karma: +5/-0
  • Offline Offline
  • Posts: 5
Re: LisaEm 1.2.7-UNSTABLE support bug reports
« Reply #151 on: February 14, 2022, 12:14:56 am »

I'm not sure if this is an appropriate place to mention this, but since this involves discussion on the upcoming release, I might as well. I made a couple of Big Sur style icons for LisaEm. I can post them here if anyone is interested; I also uploaded them on macosicons. If you want to use them for future versions of LisaEm, you are welcome to.
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +45/-1
  • Offline Offline
  • Posts: 682
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-UNSTABLE support bug reports
« Reply #152 on: February 14, 2022, 05:04:47 am »

I'm not sure if this is an appropriate place to mention this, but since this involves discussion on the upcoming release, I might as well. I made a couple of Big Sur style icons for LisaEm. I can post them here if anyone is interested; I also uploaded them on macosicons. If you want to use them for future versions of LisaEm, you are welcome to.

Sure, please do. Zip them up or tar them up with .tar.xz and post here.
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

andrew

  • Newbie
  • *
  • Karma: +5/-0
  • Offline Offline
  • Posts: 5
Re: LisaEm 1.2.7-UNSTABLE support bug reports
« Reply #153 on: February 14, 2022, 05:52:31 pm »

I attached them here. I did one for the Lisa 1, and another for the Lisa 2.
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +45/-1
  • Offline Offline
  • Posts: 682
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-UNSTABLE support bug reports
« Reply #154 on: February 15, 2022, 07:19:28 am »

I attached them here. I did one for the Lisa 1, and another for the Lisa 2.

Thank you, much appreciated.
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +45/-1
  • Offline Offline
  • Posts: 682
  • writing the code,writing the code,writing the code
    • LisaEm
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +45/-1
  • Offline Offline
  • Posts: 682
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC4 support bug reports
« Reply #156 on: May 11, 2022, 01:58:57 pm »

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.
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +45/-1
  • Offline Offline
  • Posts: 682
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC4 support bug reports
« Reply #157 on: May 20, 2022, 04:46:47 pm »

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.

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.
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code
Pages: 1 ... 9 10 [11]   Go Up