Hi Turbon,
the AB-1.12 will be a naked board for analog prototyping. In order to do anything with it you'll have to populate it with whatever feature you wish to prototype. Then you need to plug in an existing USB-I2S module.
The AB-1.12 will fit in the same enclosure as the AB-1.1. The board is only an add-on to the AB-1.1 with features not yet tested.
The PCM5102 is already designed in. Right now I'm working on the new suggested regulators. It's hard to tell exactly when I'll be done with it.
Børge
the AB-1.12 will be a naked board for analog prototyping. In order to do anything with it you'll have to populate it with whatever feature you wish to prototype. Then you need to plug in an existing USB-I2S module.
The AB-1.12 will fit in the same enclosure as the AB-1.1. The board is only an add-on to the AB-1.1 with features not yet tested.
The PCM5102 is already designed in. Right now I'm working on the new suggested regulators. It's hard to tell exactly when I'll be done with it.
Børge
OK, thanks Börge!
Looking forward to the naked board... Are the DAC's pin compatible or what kind of solution do you have in mind? I might have a different interpretation of the meaning of an "add-on" - should I keep the AB-1.1 and wire an add on board in the old DAC's place or will the new board replace the whole AB-1.1 board? What about a new DAC - should I then replace the AB-1.2 with the AB-1.3 board if a new DAC is invited to the widget world? Shurely there must be a way to disminish the cost by the way of an modularized approach.
Brgds
Yes, cost is reduced because you recycle the module and the box you already bought from me 
The AB-1.12 will only be an analog board. Since the two XOs are custom components I'll probably ship them with the naked board so that you don't have to strip components off what you already have. The remaining components should be easily obtained and depend on what you want to implement on the proto.
Børge
The AB-1.12 will only be an analog board. Since the two XOs are custom components I'll probably ship them with the naked board so that you don't have to strip components off what you already have. The remaining components should be easily obtained and depend on what you want to implement on the proto.
Børge
Suddenly, I'm having those already mentioned rate-change issues as well.
This is my stream0 when mpd changes from a 16/44.1 to a 24/96 wav-file:
Is there a comprehensive how-to how to deal with firmware updates? Are they possible on a linux shell (x-less system) or must/should I plug the widget in a windows machine?
Rüdiger
This is my stream0 when mpd changes from a 16/44.1 to a 24/96 wav-file:
Code:
www.obdev.at DG8SAQ-I2C at usb-0000:00:13.2-2, high speed : USB Audio
Playback:
Status: Running
Interface = 2
Altset = 1
URBs = 8 [ 8 8 8 8 8 8 8 8 ]
Packet Size = 392
Momentary freq = 181492 Hz (0x16.afc0)
Feedback Format = 16.16
Interface 2
Altset 1
Format: S32_LE
Channels: 2
Endpoint: 2 OUT (ASYNC)
Rates: 44100, 88200, 132300, 176400, 48000, 96000, 144000, 192000
Data packet interval: 250 usIs there a comprehensive how-to how to deal with firmware updates? Are they possible on a linux shell (x-less system) or must/should I plug the widget in a windows machine?
Rüdiger
Hi Onvinyl,
What version of firmware are you using?
For Linux and mpd, you need:
audio-widget-nik-2012-01-27.elf - sdr-widget - Unified firmware for audio-widget. For Linux alsa uac2 driver and mpd playback only May not work properly under Win or OSX. - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Go
The instructions to flash firmware (Linux and Windows) is in:
Programming widget firmware.txt - sdr-widget - Instructions for programming (flashing) the widget firmware - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting
If you want to use command line Linux to flash, build this program:
dfu-programmer-0.5.4.tar.gz - sdr-widget - Hacked dfu-programmer to workaround "User Page" problem. - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting
Alex
What version of firmware are you using?
For Linux and mpd, you need:
audio-widget-nik-2012-01-27.elf - sdr-widget - Unified firmware for audio-widget. For Linux alsa uac2 driver and mpd playback only May not work properly under Win or OSX. - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Go
The instructions to flash firmware (Linux and Windows) is in:
Programming widget firmware.txt - sdr-widget - Instructions for programming (flashing) the widget firmware - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting
If you want to use command line Linux to flash, build this program:
dfu-programmer-0.5.4.tar.gz - sdr-widget - Hacked dfu-programmer to workaround "User Page" problem. - Audio and Control Interface for Amateur Radio SDR and Audiophile USB-DAC - Google Project Hosting
Alex
Regulator Update
Here is a draft sch and layout for the regulator which has been discussed here lately. Any comments?
I plan to put 3 such regulators on the AB-1.12 prototype board. The regulators will not be connected to other circuitry. It will be easy to patch them into points of load at the two XOs and at the DAC.
Børge
Here is a draft sch and layout for the regulator which has been discussed here lately. Any comments?
I plan to put 3 such regulators on the AB-1.12 prototype board. The regulators will not be connected to other circuitry. It will be easy to patch them into points of load at the two XOs and at the DAC.
Børge
Attachments
I´m playing whit the AW in linux:
kernel 3.2.5
MPD 16.6
ALSA v1.0.25
Vortexbox 2.0.19
and the audio output format is always S24_3LE in UAC1 mode
and S32_LE in UAC2 mode. And I´m confused. Can someone explain the following outputs? I I think the format should be always S24_3LE .
UAC1
_____________________________________________________
Alsamixer v1.0.25 shows:
View: F3 PCM columm (audio output level no sensible to column level position)
_______________________________________________________
/card0/stream0 playing 16-44 wav file
DG8saQ-I2C at usb-0000:00:1d.7-3,high speed : USB Audio
Playback
Status: Running
Interface =3
Altset = 1
URBs = 3 [ 8 8 8 ]
Packet Size = 294
Momentary freq = 44102 Hz (0x2c.1a18)
Feedback Format = 10.14
Interface 3
Altset 1
Format: S24_3LE
Channel:2
Endpoint: 4 OUT (ASYNC)
Rates: 44100, 48000
Capture:
Status: Stop
Interface 4
Altset 1
Format:S24_3LE
Channels: 2
Endpoint: 5 IN (ASYNC)
Rates: 44100, 48000
_______________________________________________________
top shows:
USER %CPU %MEM COMMAND
root 0.3-1.0 0.9 mpd
Squeezb 0.7 3.2 squeezeserve
________________________________________________________
hw_params shows:
access: RW_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 5513
buffer_size: 22050
________________________________________________________
________________________________________________________
UAC2
_________________________________________________________
Alsamixer v1.0.25
Card: DG8SAQ-I2C
Chip: USB Mixer
Item: Clock2<->Clock 2 1 (no diff)
View: F3:[Playback]<Clock 2> Clock 2 1 F4: [Capture] This sound device does not have any... F5: [All] <Clock 2> Clock 2 1
__________________________________________________________
hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 5513
buffer_size: 22050
___________________________________________________________
/card0_stream0 plying the same file
DG8saQ-I2C at usb-0000:00:1d.7-3,high speed : USB Audio
Playback
Status: Runing
Interface = 2
Altset = 1
URBs = 8 [8 8 8 8 8 8 8 8 ]
Packet Size = 392
Momentary freq = 44105 (0x5.8360)
Feedback Format = 15.17
Interface 2
Altset 1
Format = S32_LE
Channels: 2
Endpoint: 2 (OUT (ASYNC)
Rates: 44100, 88200, 132300, 176400, 48000, 96000, 144000, 192000
Data Packet interval: 250 us
_____________________________________________________________
44100
USER %CPU %MEM COMMAND
root 07-1.0 0.7 mpd
squeezb ~1.0 3.3 squeezeboxserve
Format: S32_LE
_____________________________________________________________
24-44
root 1-2 0.7 mpd
squeezb 1-2 3.4 squeezeboxserve
Format: S32_LE
_____________________________________________________________
24-96
root 2-3 0.7 mpd
squeezb 2-3 3.4 squeezeboxserve
Format: S32_LE
_____________________________________________________________
24-88
root 2-3 0.6 mpd
squeezb 2-3 3.4 squeezeboxserve (some times higt noise on start,OK after pause/start)
Format: S32_LE
______________________________________________________________
24-192
root 5 0.7 mpd
squeezb 4-5 3.3 squeezeboxserve
squeezb 6-7 0.1 sox (??????????, my comment)
squeezb 7-8 0.0 faad(??????????, my comemnt)
Format: S32_LE
_______________________________________________________________
24-192 (LINN Master)
root 6 0.6 mpd
squeezb 3-4 3.8 squeezeboxserve
Format: S32_LE
_______________________________________________________________
Thanks in advance
Juan
kernel 3.2.5
MPD 16.6
ALSA v1.0.25
Vortexbox 2.0.19
and the audio output format is always S24_3LE in UAC1 mode
and S32_LE in UAC2 mode. And I´m confused. Can someone explain the following outputs? I I think the format should be always S24_3LE .
UAC1
_____________________________________________________
Alsamixer v1.0.25 shows:
View: F3 PCM columm (audio output level no sensible to column level position)
_______________________________________________________
/card0/stream0 playing 16-44 wav file
DG8saQ-I2C at usb-0000:00:1d.7-3,high speed : USB Audio
Playback
Status: Running
Interface =3
Altset = 1
URBs = 3 [ 8 8 8 ]
Packet Size = 294
Momentary freq = 44102 Hz (0x2c.1a18)
Feedback Format = 10.14
Interface 3
Altset 1
Format: S24_3LE
Channel:2
Endpoint: 4 OUT (ASYNC)
Rates: 44100, 48000
Capture:
Status: Stop
Interface 4
Altset 1
Format:S24_3LE
Channels: 2
Endpoint: 5 IN (ASYNC)
Rates: 44100, 48000
_______________________________________________________
top shows:
USER %CPU %MEM COMMAND
root 0.3-1.0 0.9 mpd
Squeezb 0.7 3.2 squeezeserve
________________________________________________________
hw_params shows:
access: RW_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 5513
buffer_size: 22050
________________________________________________________
________________________________________________________
UAC2
_________________________________________________________
Alsamixer v1.0.25
Card: DG8SAQ-I2C
Chip: USB Mixer
Item: Clock2<->Clock 2 1 (no diff)
View: F3:[Playback]<Clock 2> Clock 2 1 F4: [Capture] This sound device does not have any... F5: [All] <Clock 2> Clock 2 1
__________________________________________________________
hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 5513
buffer_size: 22050
___________________________________________________________
/card0_stream0 plying the same file
DG8saQ-I2C at usb-0000:00:1d.7-3,high speed : USB Audio
Playback
Status: Runing
Interface = 2
Altset = 1
URBs = 8 [8 8 8 8 8 8 8 8 ]
Packet Size = 392
Momentary freq = 44105 (0x5.8360)
Feedback Format = 15.17
Interface 2
Altset 1
Format = S32_LE
Channels: 2
Endpoint: 2 (OUT (ASYNC)
Rates: 44100, 88200, 132300, 176400, 48000, 96000, 144000, 192000
Data Packet interval: 250 us
_____________________________________________________________
44100
USER %CPU %MEM COMMAND
root 07-1.0 0.7 mpd
squeezb ~1.0 3.3 squeezeboxserve
Format: S32_LE
_____________________________________________________________
24-44
root 1-2 0.7 mpd
squeezb 1-2 3.4 squeezeboxserve
Format: S32_LE
_____________________________________________________________
24-96
root 2-3 0.7 mpd
squeezb 2-3 3.4 squeezeboxserve
Format: S32_LE
_____________________________________________________________
24-88
root 2-3 0.6 mpd
squeezb 2-3 3.4 squeezeboxserve (some times higt noise on start,OK after pause/start)
Format: S32_LE
______________________________________________________________
24-192
root 5 0.7 mpd
squeezb 4-5 3.3 squeezeboxserve
squeezb 6-7 0.1 sox (??????????, my comment)
squeezb 7-8 0.0 faad(??????????, my comemnt)
Format: S32_LE
_______________________________________________________________
24-192 (LINN Master)
root 6 0.6 mpd
squeezb 3-4 3.8 squeezeboxserve
Format: S32_LE
_______________________________________________________________
Thanks in advance
Juan
Hi Juan,
1. It is correct. uac1 the format is S24_LE and uac2 the format is S32_LE
This is because we have changed the firmware to playback at 32 bits under uac2, for two reasons:
(a) For running the PCM5102 DAC which is 32 bits.
(b) For improved SQ even with the 24 bit ES9023 DAC. (as to why this is so please read the previous posts on this subject. Hint: 32bit i2s data is processed by the ES9023 internal DSP before sending to sigma-delta modulator (at 24 bit precision.)
We have not changed the uac1 from 24 bit to 32 bit. We don't plan to The reasons are:
(a) users of the AW will be more interested in running it in uac2, to take advantage of the full capabilities;
(b) Nikolay is working on a Windows uac2 driver for the AW. We hope to have good news soon.
Alex
1. It is correct. uac1 the format is S24_LE and uac2 the format is S32_LE
This is because we have changed the firmware to playback at 32 bits under uac2, for two reasons:
(a) For running the PCM5102 DAC which is 32 bits.
(b) For improved SQ even with the 24 bit ES9023 DAC. (as to why this is so please read the previous posts on this subject. Hint: 32bit i2s data is processed by the ES9023 internal DSP before sending to sigma-delta modulator (at 24 bit precision.)
We have not changed the uac1 from 24 bit to 32 bit. We don't plan to
The reasons are:(a) users of the AW will be more interested in running it in uac2, to take advantage of the full capabilities;
(b) Nikolay is working on a Windows uac2 driver for the AW. We hope to have good news soon.
Alex
Hi Juan,
The current AW does not have hardware volume control so alsamixer under uac1 does not show any volume controllable GUI. The current versions of alsamixer does NOT support uac2 so you are seeing alsamixer trying to interpret uac2 descriptors as uac1 descriptors so it gets all confused.
We are planning future projects using DAC's that do have hardware volume control. We will address the GUI issue then. Until Linux alsamixer starts to support uac2, you can't use it to do volume control on uac2 devices. We may end up writing our own GUI to interact with the AW with volume control and other capabilities (see below).
A related issue is that uac2 has HID specifications to allow the hardware to notify the PC software of status changes etc. For example, if your audio device has a button for pause/play, then pressing the button will result in a HID message for the host PC, so that the host PC software can go into a pause/play mode correctly. We have not implemented that on the AW firmware as we are not sure of the uac2 HID support in Linux or Windows. Only OSX seems to have a full uac2 implementation at the moment.
Alex
The current AW does not have hardware volume control so alsamixer under uac1 does not show any volume controllable GUI. The current versions of alsamixer does NOT support uac2 so you are seeing alsamixer trying to interpret uac2 descriptors as uac1 descriptors so it gets all confused.
We are planning future projects using DAC's that do have hardware volume control. We will address the GUI issue then. Until Linux alsamixer starts to support uac2, you can't use it to do volume control on uac2 devices. We may end up writing our own GUI to interact with the AW with volume control and other capabilities (see below).
A related issue is that uac2 has HID specifications to allow the hardware to notify the PC software of status changes etc. For example, if your audio device has a button for pause/play, then pressing the button will result in a HID message for the host PC, so that the host PC software can go into a pause/play mode correctly. We have not implemented that on the AW firmware as we are not sure of the uac2 HID support in Linux or Windows. Only OSX seems to have a full uac2 implementation at the moment.
Alex
Please check on the power dissipation on the pass transistor Q2002. I would think 150 mA would be the max (the whole AB1.1 draws less than 250 mA). So 150 mA X 1.7V = 255 mW. I don't want anyone to have unpleasant smoke appearing so you may need a larger package and some PCB heatsinking.
UAC2 on Linux
Thanks Alex for the explanations.
So, the outputs are OK according the limitations of linux UAC2 implementation, ALSA, MPD, .... etc.... etc.
I´l accept that, but my idea about UAC2 on linux was that that was full implemented and transparent
Google servs me:
"_____________________
Most Linux players will send 16 bit data to the soundcard for 16 bit material and 24 bit data for 24 bit material.
Where the soundcard's native format differs from what an application sends, ALSA converts to the target format.
On my card, playing 24 bit material, mplayer sends 24 bit samples to ALSA and ALSA sends S32_LE data to the card (which is the only format the ICE1712 supports).
You can force the format that ALSA sends to the sound card by editing your .asoundrc.
I recommend you do this with KAsound, if you have KDE.
_______________________"
After that i will leave linux and try osx or freeBSD, waiting for Nicolay´s UAC2 for Windows.
So long linux, and thanks for all the fish.
Thanks again, Alex
Juan
Thanks Alex for the explanations.
So, the outputs are OK according the limitations of linux UAC2 implementation, ALSA, MPD, .... etc.... etc.
I´l accept that, but my idea about UAC2 on linux was that that was full implemented and transparent
Google servs me:
"_____________________
Most Linux players will send 16 bit data to the soundcard for 16 bit material and 24 bit data for 24 bit material.
Where the soundcard's native format differs from what an application sends, ALSA converts to the target format.
On my card, playing 24 bit material, mplayer sends 24 bit samples to ALSA and ALSA sends S32_LE data to the card (which is the only format the ICE1712 supports).
You can force the format that ALSA sends to the sound card by editing your .asoundrc.
I recommend you do this with KAsound, if you have KDE.
_______________________"
After that i will leave linux and try osx or freeBSD, waiting for Nicolay´s UAC2 for Windows.
So long linux, and thanks for all the fish.
Thanks again, Alex
Juan
You'll be back Juan...
I have been doing it for soon 20 years, left tired of not finding info and tired of depending on developers not able to explain more than to other developers.
This is the backside of free OS'es. They surely have their place in the toolbox but you need to know more than you might want to learn. Otherwise when it is in place it works very, very well - until someone gets a bright idea and you have to redo parts of your learning and system.
Fun? Yes, it was but now it's not as exiting it used to be. OSX is calling and maybe soon Windows as well.
I hope more attention should be given to real UAC2 implementation by the book and not customize the widget to mainly fit the one or another OS. Stick to UAC2!
Brgds
I have been doing it for soon 20 years, left tired of not finding info and tired of depending on developers not able to explain more than to other developers.
This is the backside of free OS'es. They surely have their place in the toolbox but you need to know more than you might want to learn. Otherwise when it is in place it works very, very well - until someone gets a bright idea and you have to redo parts of your learning and system.
Fun? Yes, it was but now it's not as exiting it used to be. OSX is calling and maybe soon Windows as well.
I hope more attention should be given to real UAC2 implementation by the book and not customize the widget to mainly fit the one or another OS. Stick to UAC2!
Brgds
I agree.
For one thing, there is nothing lacking from UAC2 as a standard. As far as I know, there are no complaints about UAC2 other than lack of support. But there is no need to change the standard just because support is lacking, because a different standard is only going to be even less supported.
Second, anyone willing to create a custom driver for a small-time standard should simply put those same efforts into creating a UAC2 driver. It should be no more difficult to create a driver for a new protocol than for UAC2, so why create a new protocol if it doesn't really solve anything?
Finally, I am bothered that many of the alternatives to UAC2 are based on Bulk rather than Isochronous. The problem here is that basing an audio protocol on Bulk means that audio transfers have no guaranteed bandwidth on the USB, and thus any USB storage device could take over the available bandwidth and make the audio glitch. USB may not be the best family of specifications in the history of computers, but they got at least one thing right for audio when they specified guaranteed Isochronous bandwidth. In fact, USB itself only has four types of transfers, and Isochronous was created specifically to address the needs of real-time streams that cannot afford to drop out at random when other data flows burst to higher levels.
Hi rsdio et al,
I think you did not realize what I posted about the Windows uac2 driver for the AW that Nikolay is developing.
It IS a UAC2 driver. It is ISOCHRONOUS. It follows the uac2 specs.
btw, both the AW firmware and the forthcoming Windows uac2 driver are fully UAC2 specs compliant.
What may not be apparent to many people is that there are ambiguities in the UAC2 specs. Different OS driver implementations then can interprete the uac2 specs differently, leading to minor incompatibilities. The rate feedback format is one of these ambiquities. So OSX is not out of specs. So Linux uac2 driver is not out of specs. But they are different !!!
Also, don't confuse what I said about alsamixer with uac2 driver. Alsamixer does NOT use the uac2 driver. The uac2 driver for audio playback is working fine with the AW (except the quirks with rate feedback format which I explained above). Alsamixer (written by a different team from the uac2 driver) just has not been upgraded to uac2 yet. (btw, it was a similar situation wrt lsusb. The old lsusb does not know about uac2 and so it will list warnings and errors when parsing a uac2 device. The newer lsusb versions has updated uac2 parsing and are showing uac2 device descriptors correctly.
I don't want to get into arguments about which OS is "better". It becomes a "religious" issue and to each its own.
When it comes to standards, it is naive to believe that if everyone follows the standards, all will be fine. In the real world, there will be quirks and workarounds. Only if your are a big monopoly can you dictate that everyone else has to work according to your interpretation of the "standard".
Alex
I think you did not realize what I posted about the Windows uac2 driver for the AW that Nikolay is developing.
It IS a UAC2 driver. It is ISOCHRONOUS. It follows the uac2 specs.
btw, both the AW firmware and the forthcoming Windows uac2 driver are fully UAC2 specs compliant.
What may not be apparent to many people is that there are ambiguities in the UAC2 specs. Different OS driver implementations then can interprete the uac2 specs differently, leading to minor incompatibilities. The rate feedback format is one of these ambiquities. So OSX is not out of specs. So Linux uac2 driver is not out of specs. But they are different !!!
Also, don't confuse what I said about alsamixer with uac2 driver. Alsamixer does NOT use the uac2 driver. The uac2 driver for audio playback is working fine with the AW (except the quirks with rate feedback format which I explained above). Alsamixer (written by a different team from the uac2 driver) just has not been upgraded to uac2 yet. (btw, it was a similar situation wrt lsusb. The old lsusb does not know about uac2 and so it will list warnings and errors when parsing a uac2 device. The newer lsusb versions has updated uac2 parsing and are showing uac2 device descriptors correctly.
I don't want to get into arguments about which OS is "better". It becomes a "religious" issue and to each its own.
When it comes to standards, it is naive to believe that if everyone follows the standards, all will be fine. In the real world, there will be quirks and workarounds. Only if your are a big monopoly can you dictate that everyone else has to work according to your interpretation of the "standard".
Alex
UAC2 seems to be pretty complete and capable. The implementation on Linux is pretty new and seems to work mostly. There are a few bugs I suspect and some of it is different from the OSX implementation. The Windows implementations will be interesting to explore since they may all be different. There are rumors of a native implementation in Win 8 but no real evidence yet.
If we can identify real bug or implementation issues I'm sure that getting them fixed on Linux will be possible. OSX is quite the unknown right now and there are only a few Windows driver in the field. The Thesycon is the most commpon. Tenor has one for their chip, TE8802L, which is mostly UAC2 compliant. There are some other drivers on the horizon. If I can get a chance to test them I will.
If we can identify real bug or implementation issues I'm sure that getting them fixed on Linux will be possible. OSX is quite the unknown right now and there are only a few Windows driver in the field. The Thesycon is the most commpon. Tenor has one for their chip, TE8802L, which is mostly UAC2 compliant. There are some other drivers on the horizon. If I can get a chance to test them I will.
freebsd? lol!
I ran a bsd shop for a long time and was pretty hard-headed about it, too. this was 10 yrs ago while linux was still a little young and bsd was very polished.
I have to say, its the opposite now. bsd is not well supported on a lot of hardware, its still the road much less travelled and a lot of core developers left. I'm not sure bsd has anything to offer anymore (I used to care about zfs but even that is not really cool since sun went out of business and oracle took over.)
I'm just amazed you'd think that life on the bsd side is any better.
I ran a bsd shop for a long time and was pretty hard-headed about it, too. this was 10 yrs ago while linux was still a little young and bsd was very polished.
I have to say, its the opposite now. bsd is not well supported on a lot of hardware, its still the road much less travelled and a lot of core developers left. I'm not sure bsd has anything to offer anymore (I used to care about zfs but even that is not really cool since sun went out of business and oracle took over.)
I'm just amazed you'd think that life on the bsd side is any better.