Drawterm on Void Linux

Drawterm on Void Linux

[Rodrigo G. López]

Hi,

I had problems to get audio working with drawterm after enabling the oss compat layer for alsa. The thing is, for some reason linux decides to create a /dev/dsp1 instead of a /dev/dsp, so changing $drawterm/kern/devaudio-unix.c to reflect that fixed it.

I send this in case someone has any trouble in the future. I'm using a base void linux distro and I used `CONF=unix make' to build the program.


Thanks for your time.

-rodri

Re: [9front] Drawterm on Void Linux

[mikan]

On 2019-02-22 14:27, Rodrigo G. López wrote:
> Hi,
> 
> I had problems to get audio working with drawterm after enabling the
> oss compat layer for alsa. The thing is, for some reason linux decides
> to create a /dev/dsp1 instead of a /dev/dsp, so changing
> $drawterm/kern/devaudio-unix.c to reflect that fixed it.
> 
> I send this in case someone has any trouble in the future. I'm using a
> base void linux distro and I used `CONF=unix make' to build the
> program.
> 
> 
> Thanks for your time.
> 
> -rodri

IIRC, Void Linux comes with OpenBSD's sndio support.
You will need to edit Makefiles a bit, but you can build drawterm to use
sndio for auido output as well.

Re: [9front] Drawterm on Void Linux

[hiro]

would ln -s /dev/dsp1 /dev/dsp be an alternative?

Re: [9front] Drawterm on Void Linux

[Rodrigo G. López]

I didn't actually try that, I thought about writing a udev rule to change the path but I don't really use it outside of drawterm. I also thought it would need some other flag for open(2), but it seems it gets redirected just fine.




On Saturday, February 23, 2019 08:14 CET, hiro <23hiro@gmail.com> wrote:

> would ln -s /dev/dsp1 /dev/dsp be an alternative?

Re: [9front] Re: [9front] Drawterm on Void Linux

[hiro]

just suggested it cause i guess void linux is doing it wrong, and that
might be the right way to fix it on their side.

Re: [9front] Re: [9front] Drawterm on Void Linux

[Ethan Gardener]

On Sun, Feb 24, 2019, at 6:27 AM, hiro wrote:
> just suggested it cause i guess void linux is doing it wrong, and that
> might be the right way to fix it on their side.

Years ago, it seemed to be the normal way to select which device node was the CD-ROM, etc.  It made some sense to do it that way, using common tools and recording the choice right there in /dev, but I guess it's no good when nodes get renumbered.

Re: [9front] Re: [9front] Drawterm on Void Linux

[hiro]

why would they get renumbered, there should be only one audio device
normally, or?

Re: [9front] Re: [9front] Drawterm on Void Linux

[Kurt H Maier]

On Mon, Feb 25, 2019 at 02:06:25AM +0100, hiro wrote:
> why would they get renumbered, there should be only one audio device
> normally, or?

Between on-motherboard soundcards, pci soundcards, hdmi audio, and usb
audio, that's not a safe assumption.

khm

Re: [9front] Re: [9front] Drawterm on Void Linux

[Ethan Gardener]

On Mon, Feb 25, 2019, at 1:13 AM, Kurt H Maier wrote:
> On Mon, Feb 25, 2019 at 02:06:25AM +0100, hiro wrote:
> > why would they get renumbered, there should be only one audio device
> > normally, or?
> 
> Between on-motherboard soundcards, pci soundcards, hdmi audio, and usb
> audio, that's not a safe assumption.

Indeed.  I currently have my display duplicated between monitor and TV, one or the other of which may be turned off at any one time.  Only the TV supports HDMI audio.  If you asked me how the computer should number the device corresponding to the HDMI audio, I'd have a hard time deciding.  Actually, that's not true.  I'd say it shouldn't number it at all, it should present its name, even if it means long and slightly clumsy file names.  Here's a more or less worst-case mock-up, it's not terrible:

# ls /dev/dspall
samsung__2-nvidia_high_definition_audio_
speakers__realtek_high_definition_audio_

The names are lower-cased with parens and spaces repaced by '_'.  What to do if there are multiple devices with the same name?  Well, then you have to number them, but not before.  Huh... Linux can do this for disks, so why not audio?

Re: [9front] Re: [9front] Drawterm on Void Linux

[k0ga]

>> would ln -s /dev/dsp1 /dev/dsp be an alternative?

I use "aoss drawterm" and it works out of the box without any
change to the makefile.