René Rebe

I wanted to try out Bluetooth stereo audio for some time, now, and just got myself my first bluetooth headset, ever (more on that in another post). As audiophile my first impressions where a little mixed, but eventually I figured out why they where worse under Apple’s Mac OS X, even compared to Apple’s iPhone 3G. Some excessive research turned out why (beside the crappy SBC codec mandatory in A2DP): OS X’s “BluetoothAudioAgent” may use forbidable low bit-rates for the forbidable bad audio codec by default! The straight-forward, cut’n past-able tweak is as simply as running this in your terminal:

defaults write com.apple.BluetoothAudioAgent “Apple Bitpool Min (editable)” 52

The max may be 64, however, 56 did resulted in the agent to connect to my headset, 52 worked. Please post a comment if a higher rate works for you, or you need an ever lower value (btw. the default appears to be as low as 2! …). Now with the tweaked setting a lot of the noise, hissing, and other compression artifacts experienced with A2DP under Mac OS X are gone! :-)

On the way I found out something likewise interesting: The menu extra’s (the little widgets in the top-right area of the menu) show alternate versions when clicked with the Option key hold down (unlike other, regular, option-click context menus for this easter egg a possibly enabled, real right click is not enough, you have to Option-click).

For example the WiFi one shows some internals: BSSID, PHY mode, channel, encryption, … the Audio one lets you switch your audio sources (!!!), the Battery one shows the condition, and the Bluetooth one display the version, and entries for the Bluetooth Explorer, Diagnostics Utility, and PacketLogger. Neat!

Which finally brings me to the UI way to do this tweak: Option-click the Bluetooth Menu Extra : Open Bluetooth Explorer : Utilities : Special Options… : Audio Options : For A2DP connections use these bitpool values: Minimum : 52

Personally I find the “Special Options…” particularly amusing.

By-the-way: performance metric on the side, on an underperforming Atom Z530 iTunes consumes 11% CPU (3% on a 2.2GHz MacBookPro) decoding an average MP3, and the BluetoothAudioAgent a little more than 16% (5% on a 2.2GHz MacBookPro) to encode the audio stream into the sub-standard SBC (Sub-Band-Codec). Not only would MP3 codec over A2DP support in more headsets and Bluetooth stacks save at least those 16% of the re-encoding, it would also save some of the 11% initial decoding, and improve audio quality by magnitudes!

Hardware vendors, please? Guess it’s time to bring my own advanced-codec Bluetooth headsets to the market :-)

Now this is insane, and sad:

panic(cpu 1 caller 0×21b8c6): “bad exception behavior!”@/SourceCache/xnu/xnu-1504.3.12/osfmk/kern/exception.c:298
Backtrace (CPU 1), Frame : Return Address (4 potential args on stack)
0×71c4bbe8 : 0×21b449 (0×5ce420 0×71c4bc1c 0×2238a5 0×0)
0×71c4bc38 : 0×21b8c6 (0×584e34 0xc1d7b90 0xc1be1f0 0×1)
0×71c4bee8 : 0×21ba31 (0xa175b7c 0×1 0×71c4bfa0 0×2)
0×71c4bf38 : 0×2a844f (0×1 0×71c4bfa0 0×2 0×1)
0×71c4bfc8 : 0×29e80a (0×8b55a20 0×0 0×10 0×8b55a20)

So much for Apple’s “superior OS”, and “Unix foundation” advertisements.

An OS that is catched with pants down that easily is like, well, actually, like Mac OS 9, or even worse: Windows 95, 3.1, etc. Hell, it is like DOS!!!

And this while Steve is just lulling about Flash crashing Macs. Frankly I do not remember a single crash of Safari due to Flash, … It might be slow, but at least it did not crash on me (on OS X).

Even just using Linux, Mac OS X (that is not so much Windows), why the heck does every linker needs to be have differently?

The GNU one for example can not create relocatable, static objects with hidden symbols stripped. The GNU masters just wave you off, telling you to simply ship a zillion shared-object files. When all you want is some program executable? Thanks.

Fortunately Apple’s legacy linker does even allow the above (not that it is too useful if most Unix linkers do not, …) But the Apple linker only supports this for ppc, ppc64, and i386 - that is, not for recently added x86_64. Oh my!

It could not be more bizarre, could it?

Let’s hope that LLVM eventually get’s it straight – maybe fixing the incompatible tool-chain mess in the long run, …

Update: LLVM 2.7 is out!

Thanks god I’m not only wondering how much sense cmake does make!

In the Linux world one is currently a little stuck with Ext4. Since the author of ReiserFS went into jail there is not much development happening with Reiser4 (and the plugin stuff was highly controversy anyway, I just would have wanted the FS basics, without the fancy plugin glue, anyway), and as the BetterFS is not quite there yet, your best bet in the near future gotta be Ext4, …

Fortunately there is a way to convert your existing Ext*FS to Ext4:

tune2fs -O extents,uninit_bg,dir_index /dev/theDevice
fsck -pDf /dev/theDevice

You could also just remount it with -t ext4, however this only gives you some of the new features (e.g. delayed allocations, etc.), but not the other, on-disk format changing goodies (extends et al.).

Just spotted this on my neighbors blog. Sadly I have to fully agree. The amount of upstream breakage, regressions and such, I have to deal with in T2 is beyond believe, and no fun at all.

This is one reason we still use a way older udev version, but that is not even the most broken stuff I have come by recently, …

Update: Looks like others feel the pain, too, …

So with T2 SDE I do this open source thing for over 10 years by now. I was lucky for the opportunity to already toy with an IBM XT (clone) in the 1980’s. And more lucky when my dad invested into a second floppy, a 40GB hard drive, and later a 386SX board (25MHz, with 2MB RAM) and some OAK VGA card (with NEC MultiSync monitor)! I became aquatinted with DOS at that time, and while BASIC didn’t cut it for me, with Pascal and assembly. Yep, assembly. We wrote half of the programs in it at that time. Interestingly with deep knowledge in both, (Turbo) Pascal and assembler, the transition to C was not as easy as I would imagine from todays perspective.

Anyway, when Windows 95 didn’t really cut it, a friend and I start our own protected mode kernel, when we accidentally encountered Linux. The first version I tried (some Debian) sucked and scared me enough to wait another year to try [Linux] again. As it still sucked, but seeing the potential I was about to create an own distribution when I encountered ROCK Linux. We found it usable enough to contribute, and push a Desktop flavor (Desktop ROCK Linux, dRock in short). I even got a photo from this area at the end of the 1990’s:

With all projects came the usual, policy (and marketing) issues, which made me fork of try two.

T2 now comes with over 3000 packages. These are the vanilla upstream packages, not split into the artificial -lib, -doc, -noarch, -whatever slices. To compare this numbers with other, well known distributions, you can safely multiple the count with 3, or 4, …

Since data storage does not cost as much (as the before mentioned 40MB drive) I do not clean up the download upstream source archives on my primary development server for some time now. While working on the GCC 4.5 update, it stroke me to take a look how much sources I got archived: It is 65 gig by now! Yep, that’s 65GB worth of archived open source history! As an overview the storage size for the T2 package sources of the respective release branches:

3.8G mirror/2.1
5.3G mirror/6.0
6.0G mirror/7.0
15G mirror/8.0

The 64GB are just since the Summer of 2006, … wished I’d kept more of the past – though I recently enocounted some source archive backup DVD-R. If I’m lucky it’s still readable, and I could mix in some more history for the fun of it :-)

In the past decade I lived without any Microsoft Windows flavor near me. However, for multiple reasons (e.g. being able to answer Windows questions to my parents in law) I thought it’d be a nice idea to leave the Windows 7 that came with the for occasional “let’s see how the menu item is named there” reboots.

While I initially had triple boot (via Chameleon, not GRUB, it just looks better) last autumn, it broken some time thereafter. As I said, I do not really “need” Windows for anything, less so abroad, so i left it in that un-bootable state for the time being. However, now that I injected an SSD I reinstalled anything, anyway. And just when I had everything installed and setup this stupid Windows 7 beast refused to boot, yet again (with the strange “hardware changed I can no longer boot” message I was already used to)! The Windows installer media repair function was no help, either.

The internet was silent on that matter as well (ok, guess not too many dual-booting their Hackintosh), so I invested some time to finally track this annoying thing down. After some intermitted hours of re-install and analysis it turned out the Mac OS X’s fdisk is the culprit! Zero’ing out the new and optional “disk signature” (4 bytes at offset 440 [0×1B8 in hex]) of the MBR:

— mbr.doesntwork.hex 2010-04-16 20:04:35.000000000
+++ mbr.works.hex 2010-04-16 20:04:26.000000000
@@ -25,7 +25,7 @@
0000180 bb 01 00 fc ac 3c 00 74 06 b4 0e cd 10 eb f5 c3
0000190 0a 0d 62 6f 6f 74 30 3a 20 00 65 72 72 6f 72 00
00001a0 47 50 54 00 74 65 73 74 69 6e 67 00 64 6f 6e 65
-00001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00
+00001b0 00 00 00 00 00 00 00 00 10 b8 29 01 00 00 80 00
00001c0 14 00 af fe ff ff 13 00 00 00 ad 60 49 06 00 fe
00001d0 ff ff 83 fe ff ff c0 60 49 06 c0 60 49 06 00 fe
00001e0 ff ff 07 fe ff ff 80 c1 92 0c 00 cd 0e 06 00 00

So Windows 7 (I assume since the new BOOTMGR was introduced in Vista) uses this disk ID to identify the boot device for startup, sigh!

Finally I know why Chameleon ships a custom fdisk, though their README could be clearer, e.g. using a “./” prefix in their sudo calls, and pointing out that preserving the disk UUID is vital for Windows versions since Vista.

Now after the WePad demonstration, which was just playing a mockup video inside the Windows Media Player, I guess Neofonie needs some private lessons how to build, and introduce a Linux tablet, even more so that the JooJoo tablet is already there, and is shipping:

• never ever show-cast it with Windows
• even less so if it is x86 based, there is virtually no setup cost, hell take any Linux, ChromeOS, Android or -as last resort- Ubuntu near you
• don’t claim a cheap Asian OEM device is “designed in Germany”, in times of the internet people will notice
• don’t just start importing an Asian OEM device when others (iPad, JooJoo) are already shipping, and don’t wait another half a year until your employees learned to create a Linux product, by that time the underdog is even less hot
• don’t name it like a utility to pee, the lesson should already be learned after Nintendo’s Wii

That’s was the basic introduction, as Mr. -red scarf- Neofonie is located in Berlin, too, he may feel invited to contact me for some more private Linux and marketing lessons (and Asian connections).

Then you might be surprised that Apple now forbids using your language of choice, …