The new build process leads to several news about rivendell debian packages :
Rivendell 1.1.0 has been available for several weeks, but the debian package weren’t up to date yet. After a small refactoring on my build scripts, a first (and very experimental) release of the debian packages is now available in the tryphon debian repository.
For now packages have been built for etch/stable i386 and amd64 and are available in the experimental section :
deb http://debian.tryphon.org experimental main contrib
Test with caution : I have not tested these packages yet. It’s just a first build. Feedbacks are welcome (on irc, on rivendell mailing-list or on french rivendell mailing-list).
arp-scan is a very useful network tool (.. for me). But the arp-scan debian package isn’t present in the stable/etch distribution. So, here is a simple backported package for arp-scan on etch.
The smartmontools 5.36 has some limitations with SATA disks. And the current debian stable distribution provides (only) this smartmontools release.
After a small pbuilder, here is the smartmontools 5.37 debian package for etch which provides the SAT support (especially for SATA disks).
SMART values are back in our munin instances 
Our Autres(M)Ondes mobile studio integrates for a while a NAS server dedicated to rivendell mysql and files. The first steps to set up a such server are described into the Rivendell wiki page Setting up a dedicated Rivendell MySQL and audio store server.
Here are the first rivendell debian packages for amd64, for etch/stable distribution. There are built from the debian source packages provided by the RFA repository.
Our new AMDx2 studio workstation has now its rivendell instance Thanks to Donfede from RFA for his work and his support.
The afternoon was dedicated to improve the udp link between our studio workstation and our streamer server. We’re using jack.udp since 2004 to transport sound over network.
Using jack.udp to link two jackd servers creates always an unsolvable problem : the two jackd servers aren’t synchronized. They are synchronized on their own sound card … There are always to many or not enough frames sent by the first jackd for the second one. When a buffer underflow occurs (our case between these two servers), the jack.udp lets the data into the buffer and sends to the jackd server a full period of .. zero. In pratice, we’re using a small period in the receiver jackd server, so the sound “holes” aren’t really audible. It is not the perfect solution, but we’re making web radios .. not an album mastering.
We should test netjack in a near future. It provides a real solution for this use case. But the startup dependencies between the two jackd servers could be a blocker problem.
I made two patchs for jack.udp today :
The first patch manages the support of a configurable jackname (and not the default "jack.udp") We’re using several jack.udp instances on the studio workstations and the patchbay rules can be written without known names.
The second patch fixes the support of packet index. Each jack.udp packet contains an index. But the current code sends bad indexed packets and doesn’t make an effective index check. I fixed these bugs and made a index check which only logs a message. The previous code was killing the process :-/
The debian unstable package of this patched jack.udp is available (amd64 for etch).
A small idea : the jack.udp daemon starts on our streamer server is piped with logger to log stderr jack.udp messages to syslog (2>&1 | logger -i -t jack.udp). It makes things really simple to monitor this transport critical for us.
My feed selection