SDL_PATH_DSP environment variable

[justinhaynes]

Good Evening!

Does fs-uae honor and use the SDL_PATH_DSP environment variable? I thought it might since I discovered the SDL_VIDEO_WINDOW_POS environment variable in fs-uae's environment when launched from fs-uae-launcher.

The reason I care about this is that I am trying to capture video and audio from the Bard's Tale games as part of a video series I am creating to document all Bard songs across all the Bard's Tale games for all (10) platforms. They differed in several ways and I find the story interesting since I was obsessed with the game as a child.

fs-uae seems to be ignoring this variable however, because it does not play through the /dev/audio2 device I want it to play through and instead plays through /dev/audio which is a symlink to /dev/audio1. I need it to play through /dev/audio2 so that it will be made available as /dev/pad0 which is a pseudodevice I can capture audio through using ffmpeg.

For this conversation, I'm only addressing the audio, since that must work first. capturing video is pretty trivial, it is the audio I am worried about.

I know this method works, because the example from Chapter 10.3 pf the NetBSD handbook works: (https://www.netbsd.org/docs/guide/en/chap-audio.html).

NetBSD still uses OSS and supports audio capture through creation of a pseudo device. When a program uses /dev/padXX devices, a corresponding /dev/audioXX device is created so that a program can be directed to send audio to the created /dev/audioXX device and that audio can be captured from /dev/padXX. We feed the program which needs to know about /dev/audioXX said device through the SDL_PATH_DSP environment variable as described in the article I linked to.

So my first step is to run the following ffmpeg command. This is only relevant to the discussion to explain that the audio devices we are dealing with do actually exist before we try to use them:

bash-5.1$ ffmpeg4 -f s16le -ar 44100 -ac 2 -i /dev/pad0 -f wav output.wav

This immediately causes the following on the system console:

[ 11052.6922972] pad0: outputs: 44100Hz, 16-bit, stereo
[ 11052.6922972] audio2 at pad0: playback
[ 11052.6922972] audio2: slinear_le:16 -> slinear_le:16 2ch 44100Hz, blk 1764 bytes (10ms) for playback
[ 11052.6922972] spkr3 at audio2: PC Speaker (synthesized)
[ 11052.6922972] wsbell at spkr3 not configured

In fs-uae-launcher I do have the audio configured to be 44100Hz.

I have attempted the following using fs-uae-launcher version 3.0.5, because this is the verison included in the pkgsrc (the system which ports many softwares to netBSD) distribution available for NetBSD 9.2 which is the version I am running

I run this:

$ SDL_PATH_DSP=/dev/audio2 fs-uae-launcher

Then I spin up the game I want to play and fs-uae is launched. I should say here that when using this normally without the environment variable, everything works just fine and I can see video, play the game and hear the audio. The audio is a bit choppy at times, but I haven't gotten so far as to troubleshoot that just yet. proc for the only of the 4 cores it runs on never goes above 35%.

I observe that fs-uae inherits the environment as shown. The following shows both fs-uae-launcher and fs-uae processes with their environments:

$ ps aux -ewww | grep fs-uae | grep -v grep
justin  7562 18.4  1.4 2503956 117076 pts/2 Ol+  11:33AM 0:08.18 _=/usr/pkg/bin/fs-uae-launcher SDL_PATH_DSP=/dev/audio2 PATH=/bin:/usr/bin:/usr/pkg/bin:/usr/local/bin:/usr/X11R7/bin SHELL=/bin/ksh XTERM_VERSION=XTerm(366) USER=justin WINDOWPATH=5 DISPLAY=:0 HOME=/home/justin PWD=/home/justin/FS-UAE/Cache/Logs WMAKER_BIN_NAME=/usr/pkg/bin/wmaker XTERM_SHELL=/bin/ksh TERM=xterm WRASTER_COLOR_RESOLUTION0=4 WINDOWID=20971532 XTERM_LOCALE=C LOGNAME=justin LC_CTYPE=C.UTF-8 SDL_VIDEO_WINDOW_POS=1919,179 /usr/pkg/bin/fs-uae /tmp/tmpa28vsqod.fs-uae --window-x=1919 --window-y=179
justin  3497  0.0  1.2  501340  96068 pts/2 Sl+  11:32AM 0:01.35 _=/usr/pkg/bin/fs-uae-launcher SDL_PATH_DSP=/dev/audio2 PATH=/bin:/usr/bin:/usr/pkg/bin:/usr/local/bin:/usr/X11R7/bin SHELL=/bin/ksh XTERM_VERSION=XTerm(366) USER=justin WINDOWPATH=5 DISPLAY=:0 HOME=/home/justin PWD=/home/justin/FS-UAE/Cache/Logs WMAKER_BIN_NAME=/usr/pkg/bin/wmaker XTERM_SHELL=/bin/ksh TERM=xterm WRASTER_COLOR_RESOLUTION0=4 WINDOWID=20971532 XTERM_LOCALE=C LOGNAME=justin /usr/pkg/bin/python3.8 /usr/pkg/bin/fs-uae-launcher

You can see there that the SDL_PATH_DSP is inherited.

However, the game comes up and plays the audio just fine. This is not expected, because this means the audio is being sent to /dev/audio or /dev/audio1 and not to /dev/audio2.

Also, ffmpeg4 never sees a stream and so never starts recording. If it had, I should hear silence.

If any of you know how I can tell fs-uae to use /dev/audio2, I'll be very appreciative!

I would have included the dmesg output showing the device creation as I ran the commands above, but I forgot to do so when I was drafting this message.

Thanks!,

Justin

[justinhaynes]

I should offer a couple of updates to this since I wrote it a couple of days ago:

1. I selected NetBSD because I could install all 11 emulators required including this one by simply running "pkgin install <emulator name>" So if NetBSD seems a bit obscure it is because packages were available for all.

2. Suspecting that I might run into other problems with NetBSD and capturing audio, I switched to Slackware. Amiga (being lower in the alphabet) was one of the first I had tried to capture video and audio for, so I thought rather than try each of the other emulators first, I'd get Amiga right and see if it is easier on LINUX.

3. Finally, this question is still relevant but less urgent now. I will post if my experience is different in LINUX. I believe with alsa this becomes a moot point but I'm not certain.

Thanks all!

[redblade]

I'm not having much luck with NetBSD 9.2 amd64. I have my old laptop which is cheap and doesn't have a driver for the WiFi Card, and my new laptop where the WiFi works but X doesn't support the internal intel Gfx Chip.

Justinhaynes: Do you buy specialist hardware for your NetBSD boxes or you don't buy cheap shitty laptops?

[justinhaynes]

Redblade - My laptop wifi was also not supported. I added a "TP-Link USB WiFi Adapter for PC(TL-WN725N), N150 Wireless Network Adapter for Desktop" which worked just fine with NetBSD.

It got fussy about the trackpad and keyboard device as well. It's a Dell laptop, which was top of the line at the time, but is years old. It was an i7 with 4 cores.

If NetBSD drivers work anything like OpenBSD, there would be an /etc/firmware folder wherein firmware could be dropped. I suspect LINUX distros may support most of that with binary blobs. I don't prefer that approach.

With Slackware LINUX 14.2 which I just loaded (it's 4-5 years old!!), the pointer and keyboard work jsut fine but wifi and the usb wifi does not. I should follow Current for that. I'd have used Fedora, but I had media issues. Fedora has a 2GB iso and some other large installer which just aren't options for me right now, so I installed with the 45Mb usb image from Slackware.

You will likely have to dig to make it work. If I end up with a workable platform for this project I'll stick with it. Otherwise I may have to put it on the shelf for a while. I'm not willing to buy a Windows machine to dedicate to this project, though I suppose I could give up and use windows on this laptop and probably be fine.

My main reason for not wanting to use Windows is that if I do it the BSD or LINUX way, I don't have to change my way of doing things for long periods of time. When Windows changes things then there is probably impact to how I'm using 11 different emulators which will have to all adapt to the new platform. It may take longer to figure out how to do what i want, but that way of working can stay put for a while.. Then of course it's open source and most of it is free software.

[FrodeSolheim]

FS-UAE uses OpenAL for audio output (*), so SDL_PATH_DSP will not be respected no. Instead, you need to configure OpenAL Soft via

~/.alsoftrc

.

(*) This is changing in FS-UAE 4, where SDL audio is used by default.

[redblade]

@justinhaynes: Yeah the linux kernal supports all of my hardware as to be expected with such a big group of developers working on it. I was thinking of using NetBSD Ethernet to Raspberry PI Ethernet -> Raspberry PI Wifi.

I quite like NetBSD as it's rather small and I'm happy with twm/athena and bourne shell. I will have a look at that network card that you mentioned for my 1xUSB3 port on that old laptop.

I also don't like wasting old hardware when it can still be used for something.

[justinhaynes]

FrodeSolheim, I see! It seems the following example lines from alsoftrc.sample would do the trick.

##
## OSS backend stuff
##
[oss]

## device: (global)
#  Sets the device name for OSS output.
#device = /dev/dsp

## capture: (global)
#  Sets the device name for OSS capture.
#capture = /dev/dsp

##

If I move back to NetBSD I would use that, but now that I'm on LINUX I will use one of the other sections. There are sections there for alsa, jack and pulse. I'm leaning toward jack because of the flexibility and my having used it before.