My problem with networking

After my two parter on networking, IPv6 and wireless, I got a few questions on why I don just use a cable connection rather than dealing with wireless bridges. The answer is, unfortunately, that I don’t have a clean way to reach with a cable from the point where my ADSL is and where my office is, on the floor above.

This is mostly due to bad wiring in the house: too little space to get cables through, and too many cables already in there. One of the projects we have going on the house now (we’ve been working on a relatively long list of chores that has to be done since neither me nor my mother foresee leaving this house soon), is to rewire the burglar alarm system, in which case, I should get more space for my cables — modern burglar alarms do not require the equivalent of four Ethernet cables running throughout the house.

Unfortunately that is not going to be the end of the trouble. While I might be able to get the one cable running from my office to the basement (where the cable distribution ties up) and from there to the hallway (where the ADSL is), I’m not sure of how many metres of cables that would be. When I wired with cat5e cable between my office and bedroom (for the AppleTV to stream cleanly), I already had to sacrifice Gigabit speed. And I’m not even sure if passing the cable through there will allow the signal to pass cleanly, as it’ll be running together with the mains’ wires — the house is almost thirty years old, I don’t have a chance to get separate connection for the data cable and the power; I’m lucky enough that the satellite cable fits. And I should shorten that.

To be honest, I knew a way around my house if I wanted to pass a cable to reach here already. But the problem with that is that it would require me to go the widest route possible: while my office is stacked on top of the hallway (without a direct connection, that would have been too easy), to get from one to the other, without the alarm rewiring, I would have to get to the opposite side of the house, bring the cable upstairs and then back, using a mixture of passageways designed for telephone, power and aerial wiring; and crawling outside the wall for a few metres as well.

The problem with that solution, beside the huge amount of time that it would require me to invest in it, is that the total cable length is almost certainly over a hundred metres, which is the official physical limit of cat5e Ethernet cables. Of course many people would insist telling me that “it’s okay, there are high chance it would still work” .. sure, and what if it doesn’t? I mean I have to actually make a hole in the wall at one place, then spend more than a day (I’m sure I wouldn’t be able to do this in just a day, already had to deal with my wiring before), with the risk of not getting a clear enough signal for the connection to be established. No thanks.

I also considered the option of going fibre optic. I have no clue about the cabling itself, and I know it requires even more specific tools than the RJ45 plugs to be wired, but I have looked at the prices of the hardware capable of converting the signal between fibre and good old RJ45 cabling… and it’s way out of my range.

Anyway, back on topic of the current plan for getting the cable running. As I said the current “cable hub” is in the basement, which is mostly used as a storage room for my mother’s stuff. She’s also trying to clean that up, so in a (realistically, remote) future I might actually move most of my hardware down there rather than in the office — namely Yamato, the router itself (forwarding the ADSL connection rather than the whole network) and Archer, the NAS. Our basement is not prone to floods, and is generally cool in the summer, definitely cooler than my office is. Unfortunately for that to work out, I’ll probably need a real-life rack, and rackmount chassis, neither of which is really cheap.

Unfortunately with that being, as I said, in the future, if I were to pass the cable next month from there, and the signal wouldn’t be strong enough, the only option I’d have would be to add a repeater. Adding a repeater there, though, is troublesome. As I said in the other posts, and before as well, my area is plagued with a very bad power supply situation. To the point that I have four UPS units in the house, for a total of 3750 VA (which is, technically, probably more than the power provided by supplier). I don’t really like the idea of having to make room for yet another UPS unit just for a repeater; even less so considering that the cables would end up being over my head, on the stairs’ passage (yes it is a stupid position to add a control panel in the first place), and while most repeaters seem to be wall-mountable, UPS units are a different story.

So the only solution I can think for such a situation would be to add a PoE repeater there, if needed, and then relay its power through a switch, either in my office (unlikely) or in the hallway near the router (most likely), behind the UPS. Once again here, the factor is the cost.

Honestly, even though I decided not to get an office after seeing costs jumping higher and higher – having an office would increase my deductibles of course, but between renting the office, daily transportation, twice the power bill, and so on so forth, it’s not the taxes that worry me – I wonder if it is really as cheap as I prospected it to be, to keep working at home.

Sigh. I guess it’s more paid work, less free time next year as well.

Some UPS notes (apcupsd et al)

If you didn’t notice, one of the packages I’ve been maintaining in Gentoo is apcupsd that is one of the daemons that can be used to control APC-produced UPS units. But for quite a while, my maintenance of the package was mostly limited to keeping it in a working state (with a wide range of different results, to be honest), since from the original (messy) ebuild I originally inherited, the current one is quite linear and, in my opinion, elegant.

But in the past two weeks or so, a few things happened that required me to look into the package more closely: a version bump, a customer having two UPSes connected to the same system, and the only remaining non-APC UPS in my home office declaring itself dead.

The version bump was the chance for me to finally fix the strict aliasing issue that is still present; this time, instead of simply disabling strict aliasing (quick, hacky way) I decided to look at the code, to make it actually strict aliasing compliant. This might not sound like much, but this kind of warnings is particularly nasty as you never know when it will cause an issue. Besides, it caused Portage to abort in stricter mode, that is what I use for packages I maintain myself.

Also, while my customer’s needs didn’t really influence my work on apcupsd itself, it caused me to look even more into munin’s apc_nis plugin as beforehand it was not configurable at all: it only ever used localhost:3551 to connect to APC NIS interface, which meant that if you wanted to change the port, or make it only listen on an external interface, you were out of luck. The patch to make this configurable is now part of Munin trunk, but I haven’t had time to ask Jeremy to add it to Gentoo as well (the few patches of mine to Munin are all merged upstream now, and Munin 2 will have those, and finally, native IPv6 transport, which means I probably won’t need to use ssh connections to fetch data over NAT, but just properly-configured firewalls).

There is another issue that comes up when having multiple UPS connected to the same box though: permanence of device names. While the daemon auto-discovers a single connected APC device, when you have multiple devices you need to explicitly tell it to access a given one. To do so, you could use the hiddev device paths, but the kernel does not make those persistent if you connect/disconnect the units. To solve this issue, the new ebuild for apcupsd that I committed today uses udev rules to provide /etc/apcups/usb-${SERIALNO} symlinks that you can use to provide stable reference to your apcupsd instances. I sent the rules upstream, hoping that they’ll be integrated in the next release.

A note here: while I’m a fan of autoconfiguration, I’m having trouble considering the idea of having apcupsd auto-started when an APC UPS is connected. The reason is not obvious though: while it would work fine if it was the only UPS and thus the only apcupsd instance to be present, if you had a second instance set up for a different UPS there would be no way to match the two together. This is at a minimum bothersome.

Speaking about init scripts, the powerfail init script currently only works in single-UPS configurations (whereas the main init script works fine in multiple UPS configurations), and even there it is a bit … broken. The powerfail flag can be written in a number of different places – the default and the Gentoo variants also point to different paths! – but this script does not take that into consideration at all. More to the point, the default, which uses /var/run might not be available at the shutdown init level since that would probably have been unmounted by that time. What I should do, I guess, is make it possible for the init script to fetch the configured value from the apcuspd configuration file, and move the default to use /run.

Next problem in my list is that apcaccess should not be among the superuser binaries, since it can be run from user just fine, but I’ll have to get that cleared with upstream first, it might break some scripts to move it in Gentoo only.

Finally, there is the problem that the sources of apcupsd are written with disregard for what many consider “library-only problems” – namely PIC – and has a very nasty copy-on-write scorecard. Unfortunately, some of the issues are so rooted into the design that I don’t feel up to fix the sources myself, but if somebody wanted a project to follow and optimise, that might be a good choice in this respect.

Sigh. I hope to find more time to fix the remaining issues with the scripts soon. For now if you have comments/notes that I might have missed, your feedback is welcome.

The hardware curse

Those reading my blog or following me on identi.ca might remember I had some problems with my APC SmartUPS, with a used up battery that didn’t work properly. After replacement, I also had some troubles (which I’m not yet sure are worked out now to be honest); and at the end I settled for getting a new one to replace or work side-by-side it if it’ll work out properly. This is why in the photo above you can see two UPSes and one box (Yamato), even though there are actually three here (just one other turned on right now, though).

I’m not sure what has caused it, but since a little before I actually started activity as a self-employed developer and consultant, I’ve had huge hardware failures: two laptops, the very same week (my mother’s iBook and my MacBook Pro), the drum of the laser printer, the external iomega HD box (which was already a replacement for the same model failing last November), and lastly the (software) failure of the PCI soundcard.

Around the same time I also ended up needing some replacement for hardware that was now sub-optimal for my use (the Fast Ethernet switch was replaced by a Gigabit one because now there is Merrimac – my iMac – always turned on, and it makes heavy use of networking (especially with iSCSI), the harddisk, which there themselves replaced just last March, and helped out by one out of two disks in the external box, started being too small (thus why I got an extra one, a FreeAgent Xtreme running on eSATA, for one more terabyte of storage), my cordless phone required me to get another handset so that my mom’s call wouldn’t get to bother me, my cellphone (just recently) is being phased for a Nokia E75 so I could get a Business account (it was a Nokia E71 before), I got an HP all-in-one so that I had an ADF scanner to go in pair with the negative film scanner for archive purposes, and some more smaller things to go with that. I should also update, again, the router: after three years of good service, my 3Com starts to get the hit of age, and also starts to hit on limitations, including the very artificial limit of 32 devices listed in the WLAN MAC-addresses (and the fact that it doesn’t support IPv6).

Then there have been costs much more tied to work (not like the stuff I have mentioned is not part of my job anyway), like proprietary software licenses (Parallels Desktops, Visual Studio 2008, and soon Microsoft Office, Avira and Mac OS X Snow Leopard) and the smartcard reader. And of course rents for the new vserver (vanguard) and phone bills to pay. Given the amount of work my boxes do during the day, I’ll soon switch the power company over to me rather than my family and pay for that too, unless I decide to move the office on a real office (possibly one I can stay at any hour), and just keep one terminal at home or something like that (but then, what would I keep?). Oh and obviously there are a few more things like business cards and similar.

Now, all these are work expenses, so they are important up to a point; I actually get paid well enough to cover for these at the moment, even though I have now a quite funky wishlist which includes both leisure-related and work-related items (you’re free to help me with both, j/k). The problem is that I would have been much better off if I didn’t have all this mess. Especially considering that, as I have said before, I really wish I could get out of home soon.

But anyway, this is still work time!

Tinderbox suspension for a few days

If you’re following me on bugzilla, or looking at the feed of new bugs reported, or just are watching the trackers for the bugs I usually report most often (gcc 4.4 and glibc 2.10 failures mostly), you might have noticed that I haven’t been opening new bugs for a few days already. Please note that this is not a stable situation, it’s just a temporary setback, caused by – you guess – an hardware failure (you could answer this more quickly if you were following me on identi.ca since I have been writing about it).

This time the problem is the UPS’s battery that have consumed after two and a half years (which actually explains pretty well how it was that this year I won two APC gadgets, after years of filing in questionnaires). As soon as the load reaches 40%, the battery charge result to last for 1 to 3 minutes max, which is not right and certainly not enough to shut Yamato down from a tinderboxing run. I have also to note that the power load on the UPS varies between 27% almost idle, and 60% during full-blown build of all the cores which is what the tinderbox does.

I’ve called my supplier on Wednesday night to order the battery, it’ll arrive to the shop next Monday, but I’ll only be able to pick it up on Tuesday (since I have a work appointment and I’ll be around that place). During this time, I’m trying to keep the load on the UPS to the minimum so that it has at least a few minutes to stop everything down; this obviously includes not having the tinderbox running full time.

Myself, trying not to load the box with my own usage, I’m trying to take a few days to work on my paid job (that requires me to use Merrimac instead, which is on a different UPS, which as far as I can tell, is for now still keeping up), reading and watching a few films I’ve gotten lately and haven’t had time to watch, maybe I’ll be able to play a bit too, but I’m not counting on it much, I have already a full weekend with my job tasks.

In the past ten days I was able to read from cover to cover John Grisham’s The Rainmaker – I don’t particularly like lawyers; I don’t particularly dislike them either. I don’t know why I tent to devour Grisham’s books this way (the first I read, in Italian, The King of Torts, I finished during a whole night!). At any rat eI’m trying to resume my average reading, in 2007 I read 19 books, last year just seven; while of course the reason why I read so many more in 2007 is tied to the 42 days of hospital I went through, and the months that it took for me to recover, I’d like to at least reach 13 books this year. It’s also a sort of way to try cooling off before I burn out.

Anyway, will be back soon.

Enel: cosa vuoi spaccare oggi?

Ho già scritto tempo fa riguardo i miei disservizi con Enel ma si trattava della scorsa estate. Dopo quei blackout ce ne sono stati altri, a volte dovuti al mal tempo (quindi comprensibilissimi) altre volte senza spiegazione. A inizio anno è capitata una sera in cui si sono verificati due scatti (cadute di tensione istantanee), senza temporale o altro che potesse spiegarlo.

Ma d’accordo, una sera può capitare. Il problema è che è appena ricapitato. E non c’è temporale. E non c’è nessun avviso. E sono stati quattro scatti stavolta.

Qualcuno deve spiegarmi perché sempre in questa zona, da vent’anni da quando abitiamo qua. Vai a due vie di distanza e non hanno blackout a meno di trombe d’aria, vai in un comune limitrofo e neanche sanno cosa siano i blackout che durano più di mezz’ora, quando qua ne abbiamo da cinque ore al colpo, almeno una volta l’anno.

Enel, non sono molto contento del servizio, affatto.

Ora, TV, PlayStation 3 e AppleTV sono fuori dai gruppi di continuità, credo sia una buona idea prenderne uno nuovo, chissà che la APC mi rottami il vecchio Mustek.

Aggiornamento delle ore 2am: anche se il simpatico ominio che ha risposto a mia madre all’ufficio segnalazione guasti questo pomeriggio aveva assicurato che il problema era stato risolto, la verità era molto diversa. In effetti il guasto, grosso, molto grosso, non era stato identificato questo pomeriggio.

E puntualmente alle 21, altri scatti, e blackout, 803500 riporta che il problema sarà risolto “in dieci minuti”; dopo venti minuti riporta invece che la corrente ritornerà presumibilmente entro le ore 22:15; alle 22:30 il messaggio era stato rimosso e l’operatore mi riferisce che, purtroppo, il guasto è stato più grosso del previsto e in effetti sarà da attendere fino a mezzanotte. A mezzanotte e un quarto ovviamente il problema non è risolto, mi assicurano però che nel giro di massimo mezz’ora il gruppo elettrogeno entrerà in funzione.

All’una e dieci, mancando ancora corrente, mi spiegano che tipo di guasto è stato: un cavo di media tensione (ventimila volt) ha avuto un problema di isolamento e un palo scaricava a terra, causando i primi scatti. Pare però che questo abbia causato una fiammata alla vicina cabina di trasformazione, che a sua volta ha pregiudicato tre cabine di distribuzione. Poiché ripassare il cavo all’una di notte, sotto la pioggia, era un po’ difficile hanno deciso di andare per la costosa via di chiamare dei gruppi elettrogeni. Però due non sono stati abbastanza, e ovviamente qual’è l’area interessata dal terzo, che è stato chiamato da Treviso? La mia.

Domani comincierò a vedere per fare una bella protesta generale contro Enel visto che mi pare impossibile che un cavo così, dall’oggi al domani, abbia problemi di isolamento. Più probabile che il problema di isolamento sia della zona e che qualcuno abbia ronfato sui controlli. Comunque, non è simpatico.

This PulseAudio bump was a massacre

For me at least. Lennart please test a bit before releasing :) If you need help with release, feel free to just call me (you have my IRC nick), and I can test a prerelease for you. At least this should keep to a minimum the use of patches for PulseAudio. I have yet to be able to put a copy of it in Gentoo without needing a patch.

Anyway the bump is done, PulseAudio 0.9.8 is available in tree together with the bigger brother 0.9.8-r1 for those of you using baselayout 2 (with the experimental init script, now even more important with the bluetooth USE flag, see later). Most of the keywords were dropped because of the three new dependencies.

The first dependency is mandatory and it’s gnome-extra/gnome-audio. Don’t be afraid, nobody will ask you to install anything GNOME to use PulseAudio if you don’t want to. The package only installs a set of wave audio files that are referenced by the default configuration of PulseAudio for instance for hotplug sounds. As the dep is quite lightweight, I decided to just make it mandatory.

The second dependency is bluez-libs and bluez-utils (the latter just at runtime). This is optional and controlled by the bluetooth USE flag and allows to build the module-bt-proximity module, that allows you to shut down the audio when you walk away from your PC carrying with you your bluetooth enabled phone. Unfortunately it doesn’t seem to work here, as it changes the master volume switch, but the optical output is unaffected by this. Update: Lennart told me to use spdif:0 rather than front:0 as output device (the latter is what HAL discovers automatically); with this change, the muting works. The problem then is that the E61 seems dead and back again many times in a minute…

Here comes useful the new init script. When you enable bluetooth USE flag, PulseAudio adds a dependency over bluez libs and utils, and the old init scripts will depend on bluetooth init script, this means that even if you don’t have a bluetooth device installed, it will start the bluetooth services. The new init script is smarter, and checks if you got the bluetooth proximity module loaded, before asking for bluetooth, this saves you.

Another note about the bluetooth USE flag and bt-proximity before moving to the third dependency: when bt-proximity is enabled, PulseAudio won’t start if you don’t have a bluetooth controller (a dongle) available. This means that you should either leave the dongle always inserted (or have the internal bluetooth always enabled) or disable the module from the configuration. With non-systemwide instances you can load the bt-proximity module at runtime, while with systemwide the module loading is disabled right after bootup.

Ending now with the third dependency, it’s PolicyKit. This is one of the many FooKits that comes out of RedHat/Fedora, and it’s supposedly going to be used instead of pam_limits to get access to high priority and realtime scheduling, but… it’s not well documented (or at all), so if you don’t know how to use it, don’t enable the policykit USE flag. Bugs about those, without a solution or a patch, will be closed as UPSTREAM, you have been warned.

Now the next person who’ll ask me documentation about PulseAudio will be risking my wrath ;) I’ll be working on something in the next weeks, but I still have to finish PAM guides, and since I left the hospital it has become more difficult to focus on writing those.

And by the way, today’s blackout lasted four hours. The laptop wasn’t completely charged; the cellphone and the iPod were both almost completely out of battery power, I had to connect the last two to the APC UPS that I did shut down before, but when the battery of the laptop was finishing, I did the mistake of trying to charge it on the UPS too… it shut down entirely, seems like the MacBook Pro’s power supply should NOT be used with an UPS. I’m sincerely considering a second battery for the MacBook Pro (15.4) and the cellphone (Nokia E61), so that at least I can keep them active even during blackouts, which aren’t rare at all where I live.

Boring power company

So today I woke up very early. Why? Because the power company decided to shut us down again.

It’s not unusual, the Italian ENEL is known for these service problems. It should be enough to say that the nominal voltage in Italy is still 220V, which allows them to provide, within law limits, down to 198V; while a lot of modern hardware handle 110 to 240 V, not so recent hardware doesn’t really like being served less than 200V in their European models.

So, one of the three UPSes I have is currently disconnected and shut down, as I was cleaning up the office, where I currently have just Enterprise and the WRT router. This left me with two UPSes screaming for their power. One in the office and one downstairs. The latter is even more obnoxious because there is no way to shut it down.

When I was able to get up the bed I was able to shut down the one in the office, an APC SmartUPS. It has just what you need: a power-off button. Simple as that. The Mustek downstairs doesn’t have but a “test” button that moves the sockets to battery even if the cable is inserted and has power.

Now I’m just waiting for the Mustek to die and shut down the network. Then I’ll be left playing Pokémon on the DS, and listening to podcasts and music on the iPod…

Saving energy?

Disclaimer: I’m not an expert, my physics knowledge is limited to high school classes, and I probably forgot most of it already; what I’m trying to do here is apply some low-grade math to a few numbers that got inferred out of reading about active PFC supplies around the net when I discovered I needed a new UPS. It might be accurate, in which case I’m lucky and happy, it might be totally bogus, in which case I’d like to know what is wrong, and what the truth would be. Don’t take my words from granted, and if you can give some more in-depth knowledge to either agree or disagree with this entry, I’ll see to update it.

This is a stream of consciousness entry, as I was thinking if it was worth the investment of replacing the three other PSUs I have in my home office with with active PFC, now that the UPS is replaced with the new one that supports them.

I’ve read that the improved efficiency of these PSUs is between 5 and 25… Alessio told me that it can reach 40% trying to avoid hyped values, I’ll try to make some calculations counting about a 10% saving over the size of the PSU, so that a 400W PSU replaced with an equivalent active PFC unit would save about 40W.

Now, I have three boxes in my home office, one of which is Farragut, which is turned on ²⁴⁄₇, meaning 8760 hours in an year; the PSU should be around 300W, so with a 30W saving, I would save 262.8 KWh in an year, which would then cost me (assuming the price for the second range: 1801-2640 KWh/year) €/cent 13.65 per KWh, which would be about €36 in an year. Considering the price of an active PFC unit to be about €80, in less than three years, it would have been paid back for good; if we count with the highest price, it would be about €59, so two years and I’m already in active.

The other two PSUs wouldn’t save me nearly as much, let’s say they would save me €10/year, it would take me a few years before paying them back, but then, they would help me with the noise (Farragut’s PSU’s is the most silent beside Enterprise, the other two are quite noisy) and the heat they generate.

It’s not bad after all, and saving energy is an important task nowadays anyway. But I wonder, how much can be saved for instance in my old ITIS (High School)?

I know of at least six or seven “servers” that are old PCs with ATX cases and PSUs, when I left the school three years ago; considering their age I’d suggest an average of 300W each too. That would be about 2000W and thus 200W saved by moving to active PFC equipment. They would also be active 8760 hours in an year, as most of them are active even when the school is closed during the summer; it would be already 1MWh/year saved.

Then there are about 9 laboratories with an average of 10 PCs turned on for about 9 months an average of 6 hours a day (and more than half of that time, someone is playing on them); they are usually newer so I’d suggest a 400W average PSU, saving 40W each. The save here would be 5.8 MHw/year.

For sure the price of energy for a school is lower than it is for an house, but it’s still a huge amount of energy, and money, even counting 10 eurocents per KWh, it would be about €600/year, for a single school; I don’t know how many schools like this are present in Italy, but seems like to me they can be quite a big amount of energy waste, considering the abundance of cheap hardware in their PCs, and servers.

Now that I’ve done a bit of math, I think I can say that the European Union directive that forces the use of active PFC power supplies does have a sense, and I’m glad it was issued, even if it forced me to buy a new (far from cheap) UPS.

Laptop policies on a workstation

As I bought the new UPS, I now have quite some time to work with it while I’m without power, as the two UPSes can keep the system online for about one hour without any kind of interruptions, included network access. This is quite nice, but there is one thing I was thinking of today…

When the workstations are running on UPS’s battery power, it’s comparable to a laptop running on battery, so I could be just using the same method laptops use: reduce the frequency of the CPU. At least Enterprise is able of CPU frequency scaling, so I’ve configured it to switch to power saving profile when the onbattery event is received by apcupsd.

It was actually quite simple, first of all apcupsd runs as root (although it should drop all privileges, but I’m not sure about it), and I have powersave installed and configured to handle this, so I just changed the /etc/apcupsd/onbattery and /etc/apcupsd/offbattery scripts to add a call to powersave binary, with -e Powersave on the onbattery event and -e Performance on the offbattery event; unfortunately I don’t think there is anything else beside slowing the CPU speed during UPS battery supply that can be done on a Workstation :(

Now I’m going to look to split the connection of the power cables in my home office so that the hardware that would just go in standby while I’m sleeping would be connected to a single multi-socket, which can be disconnected at once, to avoid leaving the hardware consuming power without any reason. I’d like to be able to do the same with the monitors (that otherwise would remain in standby as they can’t be shut down. If I wasn’t using the same UPS for both networking and monitors, I could probably use the UPS to shut them down and turn them back on at my command.

Sigh, I’m afraid there will be a looot of work to do, and I’m sealing envelopes, once again :(

A nice productive day

I might be sick, or just crazy, or both of them, but I still think I’m quite more productive when I have fever, or the days around that time. Yesterday I had fever, and I was knock out till late afternoon, but then I started feeling better, and I started producing.

First of all, rbot’s init script in my overlay has been updated: Subversion trunk will now create a rbot.pid file inside the bot’s directory without need for start-stop-daemon to create it itself, which means I can finally let rbot fork on its own rather than forcing it to background (which is not really a good thing to do, if it can be avoided). Thanks to tango and jbn for looking after my raw patch.

Then I decided to finish the work with apcupsd; again in my overlay you can find a new ebuild for 3.14.0 based on the one found on bugzilla, but with a new apccontrol file and a totally renewed init script. This script can be multiplied, which means you can have a /etc/init.d/apcupsd.foo link, which would then start apcupsd looking for /etc/apcupsd/foo.conf configuration file. Thanks to apcupsd authors for implementing this feature in 3.14!

I’ve also attached the two UPSes to Farragut instead of Enterprise, as the latter is not a server and might as well be offline when Farragut is still up (for instance this is the case most of the times I’m outside for the whole day, or if there is noone at home); apcupsd on FreeBSD works nicely, and doesn’t require any fiddling with configuration, neither kernel side (the ugen support is built by default) nor with permissions (as the default is to run as root, this might change in the future, but as it is it’s fine to me; I’ll be working on a better handling of permissions on device nodes for Gentoo/FreeBSD, but it’s not in my priority list at the moment). Also here, they work perfectly fine.

I was also able to fix a bug in xine-lib, with mp4/mov files playback that used version 1 rather than version 0 of the media header atom, such as files generated by FFmpeg. The bug was reported on sourceforge already but I wasn’t sure what it actually meant and where to find a sample file; when I generated the same condition by chance here, I decided to take a deeper look; unfortunately MultimediaWiki doesn’t provide much information about that, but I asked Mike to give me an account there so I can try to write something useful, maybe next time someone else needs a mdhd atom description they won’t have to look at the sources of FFmpeg to see how it’s read and generated.

Then tonight I wanted to resume my work on implementing audio conversions inside the audio output loop instead of doing it for every decoder; it’s an hard work as it probably will require rewriting a good deal of code, but it should be rewarding once it’s done. Right now there are a bunch more of flag values for capabilities, so for instance I can say if a drivers supports integer or float 32-bit samples, 64-bit samples, and if it can accept streams in a different endianness. This is important because there’s little point in doing the job of the output plugin, that might handle that transparently, for instance a big-endian stream might be decoded on a little-endian machine, then sent through PulseAudio to a big-endian machine where it will be reproduced: in this setup, xine’s endian reversal of the stream (from big to little endian) would have been superfluous, as PulseAudio would have accepted the big-endian samples, then sent them to the other machine that needed not to reverse them to reproduce them.

Anyway, right now the code is quite fragile, there’s no conversion being done, there are mostly only things that are totally broken out, there are asserts 1 == 0 used to mark the code that needs to be rewritten. But something works: I was able to remove a lot of code from the musepack decoder, as libmpcdec always produces 32-bit native-endian (or maybe little-endian, I’m not yet sure) floating point samples; previously the decoder converted all the samples back to 16-bit format, and then gave it to the audio output loop to handle… now instead it sends them directly to the output, and as PulseAudio supports 32-bit float samples, they are not converted and play back fine.

Tomorrow I’ll see to work a way to handle upsamping and downsampling of streams, the problem is that it’s not trivial to decide what to do: if a plugin supports 32-bit integer samples, but not 24-bit integer samples, it should probably upscale the 24-bit to 32-bit to avoid losing precision; if it doesn’t it might upscale it to 32-bit float, or maybe downscale it to 16-bit integers. The same applies to channel mode, if the driver doesn’t support stereo output, should it be updated to 4.0 or should it be downgraded to mono?

For sure this time I’m very happy of being working on branches: leaving the code broken for weeks, maybe months, is not something you want to do on the main development branch. And I mean it, because with the changes I’m doing, not only I’ll be changing the ABI of the library itself (well, actually not much, just a couple of structures), but more importantly I’ll be changing the audio output plugins API, as I need to feed them a sample format rather than a bits-per-sample size.

Anyway, this is not going to be something easy to complete, but it will be a noticeable improvement for Amarok users once done, especially because I want to make sure that the capabilities for “mixer” volume and “PCM” volume are cleared up, probably by deprecating one of them, so that Amarok can be changed not to use xine’s software amplification (which also sucks and I also need to rewrite in good part in this branch) if the output plugin actually supports a per-stream volume (like PulseAudio).

Sponsoring, bribing, and comfort words are welcome, as xine-lib’s audio_out code is giving me creeps.