Tag Archives: hardware

Synching an Arduino with gnome-shell-pomodoro

Having fallen in love with gnome-shell-pomodoro, I’ve stopped using my good old kitchen timer for the pomodoro sessions. The problem is I used to put the timer on top of my screen, so that my coworkers could see when I was available or not. With a software such as gnome-shell-pomodoro, this is of course not possible anymore. And here came the disturbing questions every 3 minutes…

So first, I tried to use both the software and the timer, starting them (almost) together. It was boring, and as you may guess, I stopped doing that after 2 days. I had to find something better, something lazier & a bit more clever. I therefore decided to hook up an Arduino with a flashy, blue, LCD screen to my computer and started hacking a little sketch for it. Then, I modified gnome-shell-pomodoro to send commands to the serial port when changing its state. The result was a simple, yet effective, way to show to my coworkers when I’m available or not… and in how much time they will be able to ask for a question.

Once it was working, and since I don’t like maintaining forks, I asked the upstream if it was a good idea to add support for this into the software directly, through Dbus. The answer was quite positive, so I’ve started working on adding that, wrote a python daemon and published  the arduino sketch into this repository. It’s still very rough, but usable. I’ll enhance the dbus support and usability on both sides during the next weeks, to match my daily usage and make it cleaner.

If anyone’s willing to add support for another software or enhancing the arduino sketch (it really needs a better timer), then please go ! :-)

PulseAudio network transports + Wifi

Now that I have an idea of a cool hardware for listening to music, I’ve been experimenting with pulseaudio network support. Over Wireless.

They are two ways of using pulse for network streaming : RTP and TCP. The first one was a total failure for me (using pulse 1.0). The second, however, was very straightforward to setup and is almost working perfectly. I only get micro-interruptions every 10 seconds. But that’s enough for not being suitable.

First, the upload rate is about 200kb/s, so maybe that’s too much for a cheap wireless card (I’m using the ath9k driver). According to Lennart, the problem is partly due to pulse not compressing streams over the network. One possible solution is to use the CELT codec (from Xiph), which has been designed to produce high fidelity audio with very low latency and power consumption. CELT’s features are the following:

  • Ultra-low latency (typically from 5 to 22.5 ms)
  • Full audio bandwidth (≥20kHz; sample rates from 8 kHz to 48 kHz)
  • A quality/bitrate trade-off competitive with widely used high delay codecs
  • Stereo support
  • Packet loss concealment
  • Constant bit-rates from 32 kbps to 128 kbps and above
  • A fixed-point version of the encoder and decoder (interesting for embedded boards)

Given the random network latencies, I can assume we have around 2ms using a wifi connection, plus pulse and celt, that would be something around 10ms… which would still be pretty ok. Having this would make a close alternative to Apple’s RAOP protocol that uses ALAC. Still, ALAC is lossless while Celt is limited to 128kb. So, FLAC or ALAC itself maybe ? Even if it eats more processing power, for desktop and powerful boards, that would still make sense.

To prevent multiple encodings/decodings, another trick would be to implement a server-side decoding and therefore write module for PA that supports speex, vorbis, etc. But that’s another story.

Second, this could also be a jitter/latency problem. In fact, I’m a bit more convinced this is the real problem. According to Maarten Bosmans, there’s still room for improving these things in the pulse core ; so that’s good news. I don’t understand why my wifi N card, if I’m not doing anything else, wouldn’t be able to keep up with the 200kb/s rate. But that’s only intuition here.

Conclusion: before going further, I’ve to understand first if this is a latency or bandwidth-related problem to pick the right fight.