Active PA speaker systems

March 22nd, 2012

During my high school time, I did a lot of work as a sound technician and lighting designer at all kinds of events, both as a volunteer at school and outside of school. Recently someone from the school told me that they were looking at buying a new portable speaker system, both to replace their old/broken/underpowered one and because they were paying more than a thousand euros in rental fees for additional speakers every year. They asked me if I could help them choose one. We quickly reached the conclusion that active speakers were the way to go because of their flexibility and because they would often be operated by people who didn’t know a lot about all the technical stuff.

We ended up narrowing it down to three candidates: the Yamaha DSR series, the JBL PRX600 series, and the QSC KW series. These are the top-of-the-line active systems the largest and most reputable speaker manufacturers have to offer, as of early 2012. The next step was to find a place where we could listen to all three and compare them. Thomann, the largest online shop for musical instruments and PA equipment in Europe, where we have been buying sound equipment for years, has a huge store and showroom in a small town in northern Bavaria. They ordered and set up all these speakers for us and let us listen to them for more than an hour. If the friendly sales guy ever grew tired of listening to our test songs like “He’s A Pirate” by Klaus Badelt or “Man in the Mirror” by Michael Jackson over and over again, he certainly didn’t show it.

We almost immediately ruled out the QSC: We had the QSC KW 153 three-way 15″ top coupled with a QSC KW 181 18″ subwoofer set up, but the mids and highs just sounded muddy.

Some other speakers we temporarily had in the test were some JBL Eon (by accident), which just sounded cheap compared to the others, and some RCF Art, which had crisp and powerful base, but not exactly outstanding highs.

Now we only had the JBL PRX 615 two-way 15″ top coupled with the JBL PRX618-XLF 18″ subwoofer and the Yamaha DSR 115 two-way 15″ top coupled with the Yamaha DSR 118W 18″ subwoofer left over. We tested and compared them for almost an hour: sometimes we tended towards the JBLs, other times we liked the Yamahas more.

The JBLs sounded very smooth (if you want to be mean, you could call them a tiny bit muddy) and their base stretched down to 30 Hz. On the other hand, the Yamahas had super-clear mids and highs and very precise and crisp base. After quite some discussion, we decided to go with the Yamahas. Another advantage was their significantly lower price and their more advanced DSP circuitry to protect the speakers.

They got delivered a few days ago and so far we’re really happy with them. They sound amazing: Perfect for the school’s numerous music performances. And they are powerful: Perfect for events like dances and parties.

If you’re looking for a set of high-quality portable speakers for a school, church, band or DJ, the Yamaha DSR series is most likely your best choice. They sound great, have lots of power and are well worth their money.

If you just use them for speech, a set of Yamaha DSR 112 would probably be a fine choice (I didn’t test the DSR 112, but assume they’re as good as the DSR 115 with a little less low-mids). If you’re using them for a band, go for a set of DSR 115, and if you have drums, base or anything else below 120 Hz, definitely get a pair of DSR 118W subwoofers along with them. Same goes for DJ and party use: a pair each of DSR 115 and DSR 118W should suffice to bring high-decibel, high-quality sound to a few hundred audience members.

If you have experiences with the Yamaha DSR (or the recently-released smaller DXR and DSW series), or have found other speakers in the same price range that sound better, please feel free to share them in the comments.

Integrating BIND with AD-integrated Microsoft DNS

October 26th, 2011

I recently set up BIND9 to run secondary zones for an ActiveDirectory-integrated DNS server (the reason being that I hated effectively losing internet access when I rebooted my W2k8R2 server). While that was really easy (add the Linux server to the nameservers tab in DNS Admin, allow zone transfers and notifications, add slave zones in the named.conf), I thought that it shouldn’t be too difficult to also automatically replicate AD-integrated Conditional Forwarders.

While they are easily found in the DC=DomainDnsZones and DC=ForestDnsZones branch inside the AD, it turns out that the server information is stored in dnsproperty attributes containing binary data. However, Microsoft actually provides a specification for their DNS data structures, which is certainly very commendable. But as it turns out, it appears to have been written by someone who had no clue about Endianness or how many bits are in a byte (*).
The essence is: everything is Big Endian, except for IP addresses (the spec claims they are Network Byte Order, but in reality they are Little Endian), and every occurence of “1 byte” in section 2.3.1.1 dnsProperty should be replaced with “4 byte”.

So after taking about two hours for something that I expected would only take a couple minutes to hack together, I ended up with 400 lines of code that generate a file you can include in your named.conf that will look something like this:
zone "google.com" {
type forward;
forward first;
forwarders { 74.82.42.42; 2001:470:20:0:0:0:0:2; };
};

zone "youtube.com" {
type forward;
forward first;
forwarders { 74.82.42.42; 2001:470:20:0:0:0:0:2; };
};

(For those curious, this sample configuration would point google.com and youtube.com at Hurricane Electric’s DNS server so that you get AAAA records, a.k.a. Google over IPv6)

After this worked, I decided to also pull my slave zone definitions through the same mechanism. It only took me a minute to do that.
zone "example.com" {
type slave;
file "slave_example.com";
masters { 10.0.0.1; };
allow-notify { 10.0.0.1; };
};

So here we are: BIND9 as a fully-blown sync partner for AD-integrated DNS zones. To add a zone or conditional forwarder to BIND, add it to AD, set it to replicate to all DNS/domain controllers in this domain or forest, add the BIND server to the nameservers tab and allow zone transfers and notifications, and wait for the cron job to kick in.

I ended up having to write this script in PHP because Python’s LDAP module appears to have a broken SASL implementation, and you need SASL to use Kerberos for an LDAP connection.

The PHP script takes two parameters (1. the AD server’s address or the AD DNS domain name; 2. the AD base DN) and requires a valid Kerberos ticket.
The shell script (which you will most likely want to run from a cron job), which shares much of its code with my script from ISC DHCPd: Dynamic DNS updates against secure Microsoft DNS, needs to be configured with your realm, domain, base DN, user name (principal) and path to a keytab for that user (instruction on how to generate the keytab using ktutil are in the script’s comments).

(*) After doing all this, I figured that people from projects like Samba that write open source software to re-implement or interface with Microsoft products are doing an absolutely amazing job. They most likely aren’t getting any better specs than the one I found on MS DNS (if they get specs at all), and yet still somehow create almost perfect software that is a lot more complex than the simple stuff I did here.

UPDATE 2011-10-30: Apparently, AD refuses all requests from Linux clients that come in via IPv6. To force IPv4, line 7 of the PHP script needs to be changed to $conn = ldap_connect(gethostbyname($adserver), 389);, which is also fixed in the downloadable script.

Mount ext3 VMDK in VMWare Fusion using VMDKMounter

October 22nd, 2011

VMWare Fusion 3 comes with a tool called VMDKMounter.app. It allowed you to simply double-click NTFS or FAT32 VMDKs and they would be mounted on your desktop.

VMWare Fusion 4 dropped this tool, but you can download version 3.1.3 and extract /Library/Application Support/VMware Fusion/VMDKMounter.app from the package using Pacifist (just make sure that VMDKMounter.app/Contents/MacOS/vmware-vmdkMounterTool has the sticky bit set and is owned by root:wheel after you extract it).

Next, install OSXFUSE (the successor to MacFUSE) and fuse-ext2 if you don’t already have them installed.

VMDKMounter attempts to mount EXT2 using /System/Library/Filesystems/ext2.fs/Contents/Resources/mount_ext2, so we need to create two symlinks:

cd /System/Library/Filesystems
sudo ln -s fuse-ext2.fs ext2.fs
cd ext2.fs/Contents/Resources
sudo ln -s ../../mount_fuse-ext2 mount_ext2

Now we’re all set, you can simply open a VMDK by double-clicking it, or you can right-click a VMWare VM and open it with VMDKMounter.app and automatically have all its VMDKs mounted.

If you are receiving an NTFS-3G error message when mounting a non-NTFS VMDK: that’s perfectly normal, so you can just click OK. The error message is due to VMDKMounter simply trying a bunch of file system mounters until it finds one that doesn’t fail. As far as I can tell, it tries (in that order) ntfs, msdos, ntfs-3g, hfs, ext2, ext3.

How-To: Converting Xen Linux VMs to VMWare ESXi

October 17th, 2011

I have a couple Linux VMs I created on Xen using xen-create-image (as such, they are using pygrub and have one virtual disk file per partition). Now I want to migrate those over to a VMWare ESXi box. To convert your raw Xen disk images to VMWare vmdk files, do this:

1. In VMWare Fusion or Workstation, do a basic install of Debian Squeeze onto a flat-file (not split into 2GB segments and preallocated) VMDK that is slightly larger than your virtual Xen disk with a separate VMDK for swap.
2. Downgrade it to Grub 1 using apt-get install grub-legacy, grub-install /dev/sda, update-grub (as Grub 2 is not compatible with /boot/grub/menu.lst files as generated by xen-create-image).
3. Shut down and make a copy of the VMDK.
4. Boot the VM back up and re-install Grub2 using apt-get install grub.
5. Edit /boot/grub/grub.cfg and replace root=UUID=xxxxxxxxxx in the linux lines with root=/dev/sda1
6. Shut down the VM and attach the VMDK you copied in step 3 as an additional disk (this will be the target disk for our conversion).
7. Boot it up and make sure that you’re getting a Grub2 screen (i.e. it is not booting from the copied VMDK).
8. Using mount, check that your root disk is sda1 (which usually should be the first disk, not the copied disk). Using ls /dev/sd*, make sure it sees the target disk as sdc.
9. dd if=/path/to/xen/vm/disk.img of=/dev/sdc1 bs=1048576
10. mount /dev/sdc1 /mnt; cd /mnt
11. nano etc/fstab: replace swap disk /dev/xvda1 with /dev/sdb1 and root disk /dev/xvda2 with /dev/sda1
12. nano etc/inittab: replace hvc0 with tty1
13. nano boot/grub/menu.lst: replace /dev/xvda2 with /dev/sda1
14. umount /mnt
15. Attach the new virtual disk to a VM and boot a rescue system. There, drop to a shell on /dev/sda1 and apt-get update, apt-get install grub
16. Reboot
17. Done!

Using Intel AMT’s VNC server

October 8th, 2011

Newer Intel Chipsets with vPro/Intel AMT, such as the Q57, Q67 and C206 (as long as they’re paired with a Core i5/i7 or Xeon with integrated graphics), have a feature called Remote KVM.

To use it, press Ctrl-P at the BIOS splash screen to get to the MEBx menu, set a password (minimum 8 characters, mixed case, numbers and special characters are enforced), configure the network settings (they can even match the OS’s IP address), enable Remote KVM and disable User Opt-In.

Next, download the Intel AMT SDK, extract the ZIP and open .\Windows\Intel_AMT\Bin\KVM\KVMControlApplication.exe . There, you can enable KVM as seen in the following screenshot:

KVM Status can either be set to “redirection ports” (meaning it will only be accessible to VNC clients that specifically support Intel AMT, such as RealVNC Viewer Plus or Intel’s KVM Console, the former of which costs $100, the latter of which constantly overlays a RealVNC logo on the screen), to “default port” (meaning it will be accessible on TCP port 5900 to any VNC client), or to “all ports” (which is the combination of both).
If you enable VNC access, you will also need to set an RFB Password. As I found out the hard way (Intel actually has it hidden in their documentation as well), it gets truncated at 8 characters and at the same time has the same security requirements as the general AMT password.
If you disabled User Opt-In in the MEBx menu, you can disable it here as well.

So that’s it, now you can use almost any VNC client you like (RealVNC and Chicken of the VNC work fine, while Apple Remote Desktop appears to cause the VNC server to freeze) and control the machine just as if you were sitting in front of it.
Two things I noticed: On my machine, the BIOS splash screen was not visible during a KVM connection (not even on a directly-attached screen), so to get to the BIOS I needed to blindly hit the corresponding key. Also, it is not possible to enter the MEBx menu during a KVM connection (probably for some obscure security reasons): if you hit the corresponding key, it immediately exits and continues normal bot; if you establish a KVM connection while in MEBx, you get disconnected immediately.

After about half an hour of playing with Intel AMT, I have to say it’s really cool. If you’re buying/building a home server, you should definitely consider getting a mainboard with Intel AMT 6.0 or later: You get server-grade remote management capabilities for a very small premium, which are very useful if you ever lock yourself out while remotely connected to the server.

Running Mac OS X 10.4, 10.5, 10.6 and 10.7 in VMWare Fusion 4.0

September 14th, 2011

UPDATE 2011-11-19: According to several blogs, VMWare Fusion 4.1 now officially runs Mac OS X 10.5, 10.6 and 10.7 (as long as you confirm that you have a valid license for virtualization). A VMWare TechNote confirms this, so I assume the change is here to stay. In my testing, even my 10.4 VM worked just as before.

UPDATE 2011-11-22: According to VMWare, this new feature is a bug. The TechNote linked above is no longer available and the whole thing pretty much sounds like VMWare changed their mind and/or was pressured by Apple.

Back in 2009, I wrote about how to install Mac OS X (non-Server) versions in VMWare Fusion. Since then, Apple has released Snow Leopard (which worked just fine using the exact same hints). VMWare just released Fusion 4.0 today (which officially supports Lion as a guest OS), so I wanted to see whether my old hint still works.

Fusion 4.0 no longer uses /Library/VMWare Fusion for all its support files, but is all self-contained (it even runs all its background services on-demand, which I quite like) and has its stuff in /Applications/VMWare Fusion.app/Contents/Library. So MultiMac Helper (which patches Fusion’s Mac OS X Server detection stuff to trick it into also allowing the non-Server versions) no longer worked, but worked fine after fixing the paths. Grab a copy here: MultiMac Helper 4.app

Next, I fired up my Snow Leopard, Leopard and Tiger VMs one after another. Some of them showed “No operating system found” messages, but I was able to fix that by going into the CD/DVD settings and making sure the virtual drive was enabled and set to my physical SuperDrive. It still shows that message sometimes upon boot of the guest OS, but that can be fixed by restarting the VM, shutting it down and starting it again, or hitting Ctrl-Alt-Del. It might take a few tries to get it to work (might be a timing issue?), but will eventually boot up. The boot loader shows some EBIOS errors, but those don’t seem to matter.

I have not yet tried creating new 10.4/10.5/10.6 VMs yet, but that should still work the same as before.

If you’re having any issues (and if possible fixes for those), please let me know in the comments and I’ll update my post. I’m also attaching my VMX files to this post so that you can compare yours to them if you have trouble getting it to work: SnowLeopard.vmx Leopard.vmx Tiger.vmx

I can’t help it, every time I fire up my Tiger VM (which I only do like twice a year), I get all nostalgic about the Aqua GUI. Ok, it’s horribly inconsistent (glossy white menu bar, structured semi-transparent menus and light gray title bars), but hey, it still looks cool.

Note
Before proceeding, make sure you have an appropriate license for Mac OS X. I.e., don’t install two copies if you only own one — in general, this means you need the Family Pack or an additional copy. Also, make sure that you’re allowed to virtualize your copy of OS X — in Germany that usually is fine as limitations imposed by the EULA are effectively not legally binding (which is the reason why the German computer magazine c’t was able to publish MultiMac Helper), but you will need to check what applies in your own country.

UPDATE: If you create a new VM, you need to remove firmware = "efi" from the VMX, or it will complain about the OS not being the server version at some point during boot. If you see the black BIOS-style screen right after powering up the VM, you’re fine. If you see a grey screen with the VMWare logo on it, the VM is set to EFI mode.
However, even then I have not been able to successfully boot a Snow Leopard DVD. This appears to be due to the way VMWare Fusion handles non-EFI OS X boots: Upon boot, it connects darwin.iso to the VM, loads its special bootloader from there. VMWare Fusion 2.0 and 3.0 somehow managed to do that without interfering with the Snow Leopard DVD, but Fusion 4.0 fails at that. I assume it’s not something the VMWare folks would be regression testing because Fusion 3.0 and later by default boot OS X guests in EFI mode.
So the conclusion would be (at least until someone figures out how to patch the virtual EFI) that you need to create your 10.4/10.5/10.6 VMs on VMWare Fusion 2.0 (or 3.0 which requires you to manually remove the firmware = "efi" line as well). They’ll run in Fusion 4.0 just fine.

Alternatively, you could try (haven’t tested it yet) to leave the VMX with firmware = "efi", pull an image from your OS X DVD, convert it to read/write, touch /Volumes/OS X Install DVD/System/Library/CoreServices/ServerVersion.plist (to make Fusion believe it’s a server DVD), convert it to read-only, boot it in the VM, install it. Rebooting into the OS will fail (as it does not have ServerVersion.plist), so remove the firmware = "efi" to switch the VM back to the patched non-EFI bootloader.

Xen 4.0 and Citrix WHQL PV drivers for Windows

June 18th, 2011

Xen 4.0 is supposed to be able to use Citrix’s WHQL certified Windows paravirtualization drivers. Their advantage over the GPLPV drivers is that they are code-signed, meaning they run on 64-bit Windows without disabling some of Windows’ security features.

UPDATE 2011-10-17: Signed GPLPV drivers are now available. I have not yet tested them, but I assume the fix below is no longer necessary.

While the Citrix drivers included in XenServer 5.5 work (after making a single registry tweak), the more recent ones included in e.g. Xen Cloud Platform 1.0 do not work right away:

If you install the XCP drivers, make that registry tweak and reboot the DomU, you’ll notice messages like XENUTIL: WARNING: CloseFrontend: timed out in XenbusWaitForBackendStateChange: /local/domain/0/backend/console/[id]/0 in state INITIALISING; retry. in your /var/log/xen/qemu-dm-*.log and Windows just gets stuck during boot and keeps spinning forever. To get it back to work, you’ll need to
xenstore-rm /local/domain/0/backend/console/[id]
xenstore-rm /local/domain/0/backend/vfb/[id]

after starting the VM (thanks to Keith Coleman‘s mailing list post!).

To automatically run these commands upon DomU start, create a script named /usr/lib/xen/bin/qemu-dm-citrixpv with the following contents
#!/bin/sh

xenstore-rm /local/domain/0/backend/console/$2
xenstore-rm /local/domain/0/backend/vfb/$2

sh -c "sleep 10; xenstore-rm /local/domain/0/backend/console/$2; xenstore-rm /local/domain/0/backend/vfb/$2" &

exec /usr/lib/xen/bin/qemu-dm $*
and chmod +x it.

Then, edit your DomU config file and modify the device_model line and point it to your new script:
device_model = '/usr/lib/xen/bin/qemu-dm-citrixpv'

Now your Windows Server 2008 R2 x64 HVM-DomU is all set!

Asterisk: Remotely retrieving voicemail by pressing *

April 16th, 2011

Many howtos around the internet on how to remotely access your voicemail box involve a dedicated extension reachable from the outside or an IVR menu entry. But wouldn’t it be much nicer if you could just press the * DTMF key during the announcement? Turns out, this is quite simple:

[incoming-external]
exten => s,1,Dial(SIP/1234,20)
exten => s,n,Voicemail(1234,us)
exten => a,1,VoiceMailMain(1234)
exten => a,n,Hangup()

And it even works when you’re using macros (like I am):

[incoming-external]
exten => 5551234,1,Macro(incoming-plus-voicemail,SIP/1234,20,1234)
exten => 5551337,1,Macro(incoming-plus-voicemail,SIP/1337,20,1337)

[macro-incoming-plus-voicemail] ; SIP/xxx, wait time, voicemail
exten => s,1,Dial(${ARG1},${ARG2}
exten => s,n,Voicemail(${ARG3},us)
;
push * during the announcement to access your mailbox
exten => a,1,VoiceMailMain(${ARG3})
exten => a,n,Hangup()

Asterisk: Compile SRTP Module without recompiling Asterisk

April 5th, 2011

I recently installed Asterisk 1.8.3 (the Asterisk team now provides pre-built Debian packages at http://packages.asterisk.org).
Unfortunately, that package came without the res_srtp SRTP module. (UPDATE: Starting in 1.8.4, it does come with it.) Because I didn’t feel like re-compiling the entire package, I just took the corresponding version of res_srtp.c from the SVN, added the following lines to the beginning of it:

#ifndef AST_MODULE
#define AST_MODULE "res_srtp"
#endif

and compiled and installed it using

gcc -shared res_srtp.c -o res_srtp.so -lsrtp
sudo cp res_srtp.so /usr/lib/asterisk/modules/

You’ll need to have libsrtp0-dev and asterisk-dev installed, otherwise the compile will fail.
Then, you can do sudo asterisk -r and load the module using module load res_srtp (or just restart Asterisk).

I’m still working on getting SRTP working flawlessly both incoming and outgoing and with stuff like transfers. Asterisk Secure Calling Specifics are a good starting point, but I’m also planning to write another post about this in the near future.

Asterisk: Change Callee-ID using CONNECTEDLINE

April 5th, 2011

It’s easy to change your Caller ID (assuming your phone provider doesn’t filter it) in Asterisk using something like Set(CALLERID(name)=blah). This is often used to choose which number to use for an outgoing call if you have multiple on a single SIP or ISDN trunk.

But did you know it’s just as easy to change the Callee ID on an outgoing call, i.e. change what your phone displays during the call? This can be very useful to display on the phone which one of several possible outgoing lines (multiple SIP providers, ISDN, …) was used or at which point in an IVR menu you are at the moment. To do this, use Set(CONNECTEDLINE(name)=blah). Before getting started, set sendrpid = pai in your sip.conf.

To make things easier, I created two macros in my dialplan:

[macro-connectedline-name-number]
exten => s,1,Set(CONNECTEDLINE(name,i)=${ARG1})
exten => s,n,Set(CONNECTEDLINE(number,i)=${ARG2})
exten => s,n,Set(CONNECTEDLINE(pres)=allowed)

[macro-connectedline-name]
exten => s,1,Macro(connectedline-name-number,${ARG1}, ${MACRO_EXTEN})

Now I can do things like

[internal-test]
exten => 101,1,Answer()
exten => 101,n,Macro(connectedline-name,Hello World)
exten => 101,n,Playback(hello-world)
exten => 101,n,Hangup()

in my dialplan (IVR example).

Or how about

[outgoing]
exten => 100,1,Macro(connectedline-name,Mailbox)
exten => 100,n,VoiceMailMain(${CALLERID(num)},s)
exten => _XXX.,n,Macro(connectedline-name,VoIP 1)
exten => _XXX.,n,Dial(SIP/${EXTEN}@voipprovider)

(outgoing line example).

The Asterisk Wiki also has an entire page on Manipulating Party ID Information.