Apologies if this should have been a part of #360.
Running e.g. `AbstractSound bachFugue play` resulted in no sound. Other sound-playing applications on the system were working fine.
The VM said `sound: /dev/dsp: No such file or directory`
`--help` mentioned the following - ``` vm-sound-ALSA tryLoading cogspur/lib/squeak/5.0-202003021730/vm-sound-ALSA.so: dlopen: cogspur/lib/squeak/5.0-202003021730/vm-sound-ALSA.so: undefined symbol: snd_mixer_selem_is_active vm-sound-ALSA tryLoading /home/anon/git/Cuis-Smalltalk/cogspur/lib/squeak/5.0-202003021730/vm-sound-ALSA.so: dlopen: /home/anon/git/Cuis-Smalltalk/cogspur/lib/squeak/5.0-202003021730/vm-sound-ALSA.so: undefined symbol: snd_mixer_selem_is_active ```
Running with -vm-sound-pulse gave no errors but I still got no sound.
OS - `Linux 5.5.0-1-686 #1 SMP Debian 5.5.13-2 (2020-03-30) i686 GNU/Linux`
``` $ cogspur/squeak --version 5.0-202003021730 Tue Mar 3 08:28:29 UTC 2020 gcc 5.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog-nice.2712 uuid: da64ef0b-fb0a-4770-ac16-f9b448234615 Mar 3 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid: e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020 VM: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Linux travis-job-56ef6ed6-a99c-4420-b3aa-37bf991d063a 4.15.0-1028-gcp #29~16.04.1-Ubuntu SMP Tue Feb 12 16:31:10 UTC 2019 i686 i686 i686 GNU/Linux plugin path: cogspur/lib/squeak/5.0-202003021730 [default: /home/anon/git/Cuis-Smalltalk/cogspur/lib/squeak/5.0-202003021730/] ```
Cuis5.0-4112-32.image
The VM is trying to drive sound through a broken ALSA driver. Can you try these options: $ squeak -vm-sound-pulse $ squeak -vm-sound-oss $ padsp squeak -vm-sound-oss $ aoss squeak -vm-sound-oss
In each of these sessions, you can do "Beeper beep" to test sound.
@kksubbu Sorry, I think that was some sound issue on this particular system. It works with -vm-sound-pulse on both this system (needed to restart PA, for some reason) and another Debian Testing system.
On a related note...does the VM try to detect which sound backend it should be using? It seems to use OSS by default, which doesn't seem to be a good choice for modern Linux systems 🤔
On 24/04/20 12:02 AM, contrapunctus-1 wrote:
On a related note...does the VM try to detect which sound backend it should be using? It seems to use OSS by default, which doesn't seem to be a good choice for modern Linux systems 🤔
It is difficult for the (Linux) VM to guess the sound module to be used on startup because preferred audio servers differ across distros and is user-configurable. OSS is a common denominator emulated even by modern audio servers but is getting long in the tooth, indeed. Pulse server is widely used today but there is also the ALSA server on Linux distros like Raspbian. Squeak VM also has to accommodate systems like RPi or OLPC apart from Linux, FreeBSD or Solaris (x86) laptops.
There are currently two changes being discussed.
* I have proposed a patch [1] to launch script, squeak.sh, that will detect the currently active server being used and launch the VM with the right sound module. The VM code itself will not change. This is expedient and easy to test and deploy on released VMs. * Tobias and Dave Stes have proposed changing the probing order of sound modules to pulse->alsa->oss->nas->sun so that modern servers are preferred over legacy emulation. This is a good fix for upcoming releases.
[1] https://github.com/squeak-smalltalk/squeak-app/pull/17
Regards .. Subbu
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Another possibility would be :
configure --without-vm-sound-ALSA --without-vm-sound-Sun --without-vm-sound-OSS
so in my case (on Solaris) only the pulseaudio vm-sound-pulse would be built.
Then the current selection code automatically will choose "pulse".
So in that case, which is also fine by me, pulse is choosen, without need to change the current order.
All roads lead to Rome ...
David Stes
-- Sent from: http://forum.world.st/Squeak-VM-f104410.html
"does the VM try to detect which sound backend it should be using?" not as far as I'm aware. Having such a system would be great. Look at platforms/unix/vm/sqUnixMain.c and the soundModule there-in.
On 23.04.2020, at 23:27, Eliot Miranda notifications@github.com wrote:
"does the VM try to detect which sound backend it should be using?" not as far as I'm aware. Having such a system would be great. Look at platforms/unix/vm/sqUnixMain.c and the soundModule there-in.
It tries to use the first one that loads. And this may be well OSS. (see my mail regarding default ordering).
We might need a two-stage selection here. should not be too hard.
Best regards -Tobias
You might find you have to add a function to struct Sound, such as isModulePreferred or some such to allow sqUnixMain to query the available sound modules so that they do the determination, not sqUnixMain.
On 2020-04-23, at 2:29 PM, Eliot Miranda notifications@github.com wrote:
You might find you have to add a function to struct Sound, such as isModulePreferred or some such to allow sqUnixMain to query the available sound modules so that they do the determination, not sqUnixMain.
Perhaps even better, move that stuff out of the core vm code entirely and into the platform specific sound plugin code. If you don't load the plugin (because webserver, or otherwise not needing to make noises) you shouldn't even run this code. And clearly in the image, if no noise is made no plugin should be loaded to make noises.
The only bit that should be in the core vm code is to record any preference about the sound set by the command line; the plugin code should query that and do the right thing.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim User: A harmless drudge.
I was able to get sound to play with the following code in Cuis (with `padsp cogspur/squeak ...`): ``` Feature require: #'Sound'.
SoundPlayer boinkScale. ``` Although it seems to lock the VM up with an hourglass cursor, so I can't do anything else.
Running `AbstractSound bachfugue play` produces no sound for me and CPU usage seems to go to nearly 100% for a while.
On 09/05/20 8:00 am, Oisín wrote:
I was able to get sound to play with the following code in Cuis (with |padsp cogspur/squeak ...|):
|Feature require: #'Sound'. SoundPlayer boinkScale. |
Although it seems to lock the VM up with an hourglass cursor, so I can't do anything else.
Running |AbstractSound bachfugue play| produces no sound for me and CPU usage seems to go to nearly 100% for a while.
Does the sound work when using Squeak 5.3 image under padsp?
Perhaps, sound player primitive is failing for some reason and sound is being generated in interpreted code. You could use the interrupt key while the CPU is maxed and trace the function.
Regards .. Subbu
On 09/05/20 8:00 am, Oisín wrote:
I was able to get sound to play with the following code in Cuis (with |padsp cogspur/squeak ...|):
|Feature require: #'Sound'. SoundPlayer boinkScale. |
Although it seems to lock the VM up with an hourglass cursor, so I can't do anything else.
I just cloned Cuis repo and tested it with 5.3 Linux VM (Ubuntu Linux 16.04 64b).
The first send loads packages required to produce sound while displaying the cursor. If your network is slow, this may take some time.
Running |AbstractSound bachfugue play| produces no sound for me and CPU usage seems to go to nearly 100% for a while.
Beeper beep "worked fine for me" SoundPlayer boinkScale "also played fine" PluckedSound bachFugue play "a bit loud and drove others nuts :-)" SoundPlayer stopPlayerProcess. "had to stop sound to restore peace"
HTH .. Subbu
Oh, `Beeper beep` works and doesn't freeze the UI, so I guess that was somehow specific to how `SoundPlayer` works?
vm-dev@lists.squeakfoundation.org
-
contrapunctus-1 -
Eliot Miranda
-
K K Subbu -
kksubbu
-
Oisín
-
stes -
tim Rowledge -
Tobias Pape