Content tagged deforaos

A graphical mixer for NetBSD

khorben@defora.org (khorben) — Fri, 18 Dec 2009 18:16:29 +0100

On my way to making some noise about it, I'd like to mention a few things about the Mixer program I just wrote [1].

Some background information: NetBSD [2] has an audio API of its own [3][4], which I'll call "audioio" because it sits in /usr/include/sys/audioio.h [5]. It seems to be based on Solaris' historical audio sub-system, but I've always had a hard time obtaining decent documentation about Solaris [6] on the web so I'll skip this part.

To the point: NetBSD thankfully provides an OSS emulation layer [7]. Unfortunately, it is outdated (version 3), and assumes that controls are always fixed and resemble those of the "historical" cards (eg the SoundBlaster 16 [8]). Therefore, fewer and fewer controls are actually functional, since they are implemented in totally different ways in newer sound cards.

Therefore, until recently, I had to use the native NetBSD tool, mixerctl [9], to operate with the mixer (volume controls). Just for fun, I'll paste here what it looks like on my laptop:

$ mixerctl -av
outputs.spdif.source=os  [ os adc ]
outputs.lineout.source=dac  [ dac mixerout ]
outputs.lineout.mute=off  [ off on ]
outputs.lineout=240,240  delta=4
record.lineout=85,85  delta=85
outputs.lineout.dir=output  [ input output ]
outputs.lineout.boost=off  [ off on ]
outputs.lineout.eapd=on  [ off on ]
outputs.headphones.src=dac  [ dac mixerout ]
outputs.headphones.mute=off  [ off on ]
outputs.headphones=124,124  delta=4
outputs.headphones.boost=off  [ off on ]
outputs.mono.mute=off  [ off on ]
outputs.mono=124  delta=4
record.mic=85,85  delta=85
outputs.linein.source=dac  [ dac mixerout ]
outputs.linein.mute=off  [ off on ]
outputs.linein=124,124  delta=4
record.linein=85,85  delta=85
outputs.linein.dir=output  [ input output ]
outputs.mono.source=dac  [ dac mixedmic linein mixerout lineout mic2 ]
inputs.beep.source=digitalbeep  [ digitalbeep beep ]
inputs.beep.mute=off  [ off on ]
inputs.beep=119  delta=17
inputs.dac.mute=off  [ off on ]
inputs.dac=248,248  delta=8
inputs.mic.mute=off  [ off on ]
inputs.mic=120,120  delta=8
inputs.linein.mute=off  [ off on ]
inputs.linein=120,120  delta=8
record.source=mixedmic  [ mixedmic linein mixerout mono cd lineout mic2 aux ]
record.mute=off  [ off on ]
record.master=255,255  delta=17
outputs.mic2.source=dac  [ dac mixerout ]
outputs.mic2.mute=off  [ off on ]
outputs.mic2=124,124  delta=4
record.mic2=85,85  delta=85
outputs.mic2.dir=output  [ input output ]
inputs.lineout.mute=off  [ off on ]
inputs.lineout=120,120  delta=8
inputs.aux.mute=off  [ off on ]
inputs.aux=120,120  delta=8
inputs.mic2.mute=off  [ off on ]
inputs.mic2=120,120  delta=8
inputs.cd.mute=off  [ off on ]
inputs.cd=120,120  delta=8
record.mixedmic.mute1=off  [ off on ]
record.mixedmic.mute2=off  [ off on ]
playback.mode=analog  [ analog spdif ]

That's 49 lines of cryptic controls indeed. To be fair, the mixerctl tool is great for scripts, but totally impractical when poking at the different controls just to understand what they mean and how they work.

Although, looking at the code, I found the API very interesting. In fact, it describes the different controls in terms of groups of values, sets or switches, providing their different names every time. I then imagined that I could generate an interface on the fly, based on Gtk+ [10], using sliders, checkboxes and radio buttons. It doesn't solve the whole problem understanding your own sound card, but I guess it would be much more practical this way.

It looks like this:

http://people.defora.org/~khorben/share/mixer-ad1981hd.png (ThinkPad T60, default view)
http://people.defora.org/~khorben/share/mixer-realtek-alc888-all.png (Sun Ultra 24, all controls)
http://people.defora.org/~khorben/share/mixer-realtek-alc888-all-vbox.png (Sun Ultra 24, all controls, vertical layout)

I think it's quite funny actually :)

To conclude about alternatives, I don't know how well pulseaudio [11] and others are working on NetBSD, since I'm not an avid GNOME/KDE/XFCE/etc fan. But if you have any idea or suggestion about mine, please do not hesitate! [12]

[1] http://www.defora.org/os/project/display/3305/Mixer
[2] http://www.netbsd.org/
[3] http://netbsd.gw.com/cgi-bin/man-cgi?audio+4+NetBSD-5.0
[4] http://netbsd.gw.com/cgi-bin/man-cgi?audio+9+NetBSD-5.0
[5] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/audioio.h?only_with_tag=netbsd-5
[6] http://www.opensolaris.com/get/index.jsp
[7] http://netbsd.gw.com/cgi-bin/man-cgi?ossaudio+3+NetBSD-5.0
[8] http://en.wikipedia.org/wiki/Sound_Blaster_16
[9] http://netbsd.gw.com/cgi-bin/man-cgi?mixerctl+1+NetBSD-5.0
[10] http://www.gtk.org/
[11] http://pulseaudio.org/
[12] http://people.defora.org/~khorben/place/wiki/13/Contact

gputty on Sourceforge

khorben@defora.org (khorben) — Sun, 29 Nov 2009 19:07:20 +0100

About a week ago, I had the pleasure to have a discussion on IRC [1] with a user of gputty [2]. In fact, this person had translated my project page into German and placed it on a domain of its own, gputty.de [3]!

Even though I'm not actively working on this project anymore, I was really pleased to see that is has some kind of community, with people spontaneously working on it. Therefore, I have created a project for gputty on Sourceforge [4], where hopefully more people will volunteer for this project!

Just create yourself a Sourceforge account and tell me [1] if you want access to the project. I'll happily let you contribute :)

I have already moved the project page and downloadable files to Sourceforge, and I have every intention to move its upstream source code repository over there as well. I suppose it'll be using the default SVN source code management platform in place [5].

To conclude, I'll let you know my current plan about gputty:

release 1.0.0 mostly as-is, to mark this event;
plan 2.0.0 to be using OpenSSH' own configuration files: ~/.ssh/config instead of the INI-style parser from DeforaOS.

I didn't really look for it, but I don't know any other tools doing it. Could be neat.
[1] http://people.defora.org/~khorben/place/wiki/12/About
[2] http://people.defora.org/~khorben/projects/gputty/
[3] http://www.gputty.de/
[4] http://sourceforge.net/projects/gputty/
[5] svn co https://gputty.svn.sourceforge.net/svnroot/gputty gputty

Working on the VFS again

khorben@defora.org (khorben) — Sat, 31 Oct 2009 19:02:46 +0100

I have just committed a bunch of rather heavy modifications to the AppInterface secure-RPC system from DeforaOS.

Among the significant changes:

introduced distinct interface definition files; currently expected to be installed in $(SYSCONFDIR)/AppInterface, they contain the definitions of the calls exported (they were previously hard-coded within the library)
the exported functions are still obtained automatically with dlopen(NULL)+dlsym(), but they now need to be prefixed with the name of the interface implemented (and a '_' character)

I haven't had the time to thoroughly test these changes, but I hope I will get to use this code again soon. I really want to be playing with the VFS and monitoring applications again.

About the VFS in particular, the directory listing functions should be implemented soon. Finally :)

DeforaOS Project

khorben@defora.org (khorben) — Thu, 30 Jul 2009 00:20:16 +0200

Surfing and cross-compiling glib for RunningBear

khorben@defora.org (khorben) — Sun, 29 Mar 2009 05:24:06 +0200

Yeah, it's late, we lose an hour, I was tired already, and with a broken back on top of that. I got an external patch for my back (greets to Thom), and of course when coming back home I felt like coding again.

First, I continued to work on the Gtk+ WebKit version of DeforaOS Web Surfer, which is now almost as good as it used to be. By the way, there is even a reference manual using gtk-doc.

Then, thanks to the valuable experience acquired below, I managed to fix the compilation of Xynth in RunningBear, and then I learned to cross-compile glib correctly. I was in a relatively bad mood, anticipating being homesick again in the next couple of weeks, but it turned into a quite productive evening at home :)

While I'm at it, here are a couple of (outdated) screenshots of the Web Surfer, running on hackable:1.

With the GtkHtml2 engine:
http://people.defora.org/~khorben/share/DeforaOS/surfer/surfer-hackable1-daily-gtkhtml.png

The same, fullscreen:
http://people.defora.org/~khorben/share/DeforaOS/surfer/surfer-hackable1-daily-gtkhtml-fullscreen.png

Some issues with the libc on ARM

khorben@defora.org (khorben) — Wed, 18 Mar 2009 01:18:28 +0100

Funnily enough, I currently have trouble cross-compiling applications on ARM with my libc. It used to work, but maybe I was doing things differently and I don't remember it (static linking? manual patches? less code?). Anyway, I am coming across these two problems now.

« hidden symbol `__name_here' in /some/library/path.a(_filename.o) is referenced by DSO »

This one made me lose an incredible amount of time. It usually occurs when you overrule the linker's default libraries and object files, because then a plethora of compiler-specific functions are not linked in anymore, whereas often (not always) used in the compiled code. This happens typically with "complex" mathematical functions on RISC platforms, like ARM.

Here is an illustration of the problem:
(compiling as root as I'm testing hackable:1's cross compiler in a chroot)

# ./build.sh CC=arm-linux-gnueabi-gcc all
arm-linux-gnueabi-gcc -o sh token.o scanner.o parser.o builtin.o job.o sh.o  -no
stdlib -L /root/DeforaOS/destdir-Linux-i386/usr/local/lib -Wl,-rpath-link,/usr/l
ocal/lib -l c -l gcc /root/DeforaOS/destdir-Linux-i386/usr/local/lib/start.o
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: sh: h
idden symbol `__aeabi_uidiv' in /usr/lib/gcc/arm-linux-gnueabi/4.3.2/libgcc.a(_u
divsi3.o) is referenced by DSO
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: final
link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[1]: *** [sh] Error 1
make[1]: Leaving directory `/home/khorben/DeforaOS/Apps/Unix/src/sh/src'
make: *** [subdirs] Error 2

In this case, the problem is usually solved by adding either "-l gcc" or "`gcc -print-libgcc-file-name`" to the linking flags (LDFLAGS). However, unlike my other regular platforms (i386, amd64, sparc64) here it wasn't enough. After a lot of head-banging (to be fair, it also comes from the music) I realized that this flag is necessary both when linking the libc *and* the final executable file.
« warning: type and size of dynamic symbol `choose_your_poison' are not defined »

So yeah, problem solved, right? Until the next one :(
(after hacking System/src/libc/src/Makefile so that LDFLAGS are used when linking the libc too)

# ./build.sh CC=arm-linux-gnueabi-gcc all
arm-linux-gnueabi-gcc -o du du.o  -nostdlib -L /root/DeforaOS/destdir-Linux-i386
/usr/local/lib -Wl,-rpath-link,/usr/local/lib -l c -l gcc /root/DeforaOS/destdir
-Linux-i386/usr/local/lib/start.o
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: warni
ng: type and size of dynamic symbol `lstat' are not defined
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: dynam
ic variable `lstat' is zero size
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: warni
ng: type and size of dynamic symbol `stat' are not defined
 /usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: dynam
ic variable `stat' is zero size
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: du.o(
.text+0x208): unresolvable R_ARM_ABS32 relocation against symbol `lstat'
/usr/lib/gcc/arm-linux-gnueabi/4.3.2/../../../../arm-linux-gnueabi/bin/ld: final
link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[1]: *** [du] Error 1
make[1]: Leaving directory `/root/DeforaOS/Apps/Unix/src/utils/src'
make: *** [subdirs] Error 2

Unfortunately, this one still eludes me: the fault seems to be within my libc, as it compiles fine against the glibc. Here is the incriminated code:

Apps/Unix/src/utils/src/du.c:

64 static int _du_do(Prefs * prefs, char const * filename)
65 {
66         int (* _stat)(const char * filename, struct stat * buf) = lstat;
67         struct stat st;
68 
69         if(*prefs & PREFS_H)
70                 _stat = stat;
71         if(_stat(filename, &st) != 0)
72                 return _du_error(filename);
73         if(!S_ISDIR(st.st_mode))
74         {
75                 _du_print(prefs, st.st_blocks, filename);
76                 return 0;
77         }
78         return _du_do_recursive(prefs, filename);
79 }

System/src/libc/src/kernel/linux/arm/syscalls.S:

32 /* macros */
33 #define SYSCALL(name) \
34 .global name; \
35 name:; \
36         mov     %ip, %r7; \
37         ldr     %r7, =SYS_ ## name; \
38         b       _syscall;

System/src/libc/src/syscalls.S:

217 #ifdef SYS_lstat
218 SYSCALL(lstat)
219 #endif

I tried different combinations of extra assembly-level information, like ".type name,@function; \", but only unsuccessfully so far. If you know what I should do, feel free to contact me.