Apart from Konstantin (envy24* driver author) I also got a p4 account for Yuriy (emu10kx driver author). Let’s cross fingers for a lot of collaboration in //depot/projects/soundsystem/ now…
Ryan got permission to extend the work he did in the SoC as part of a class at university. He wants to push down the new mixer stuff to the driver level now. He does it in the emu10kx driver (because he has such a card) and maybe in another driver. This will allow to use a lot more of the features a card offers. Yuriy (author of the emu10kx driver) has some work in the driver scheduled too, so I offered him a p4 account so that they can collaborate. As of this writting it is up to the p4 admins to grant an account.
And while I’m at it: Konstantin (env24* driver author) got his p4 account already. He tries to get some time to commit his work in progress there.
In multimedia@ we have a discussion about the envy24* chips. One question is how to convince companies to provide some technical information or at least free hardware samples. As part of the answer I pointed to http://www.bsdstats.org/ which may be able to provide some numbers (e.g. envy24* chips without a matching driver) which may help in negotiating some stuff with a company. Unfortunately not many envy24 chips show up there. Part of the problem may be that not enough people run the bsdstats port (and enable periodic reporting of at least the devices).
So do you have any unsupported hardware (not only limited to soundcards) or some hardware which is still up-to-date but lacks some features in the driver (this is at least the case for all recent soundcards like envy24* or HDA based ones)? Fine, run bsdstats and enable the periodic reporting. Maybe we are able to get enough numbers to show to companies so that they think it would be financially beneficial to support us in some way (free hardware, docs, technical hints, whatever).
Oh… while we are at it, the ALSA people added support for some envy24 based cards based upon the reverse engineering effort which was needed to write our driver as it is now. So if you are working for a company and reading this: if you support us, you get the Linux stuff for free too. 🙂 And as an additional bonus, you can show a working driver without any bad legal strings (e.g. GPL infection) to OEMs. So go and calculate how much sales you can do with embedded stuff and come back to us with some technical hints and/or free hardware (it costs some few bucks for you to provide this: not much if it fails but a large amount of return if it works out).
Ariffs changes two months ago to reduce the latency in the soundsystem also prepared the way for multichannel support and Yuriy added multichannel recording to the emu10kx driver (there are some bugs ATM and it is only a proof of concept to play around with it until we get real multichannel support in the generic sound code). Ryan tries to get some time (let’s cross fingers!) to convert a driver (probably the emu10kx driver) to use the new mixer infrastructure before he has to concentrate on his studies again.
This looks like we could get some very nice stuff this year.
DragonFly synced with a not so current version of our soundsystem. I had a little discussion with them and pointed out some recent improvements and some drivers they missed to sync. They don’t have the man power to participate in large improvements, but I hope for some small benefits like bugfixes or additional PCI IDs. I also pointed out the wiki page, maybe we can get some additional sentences (we are lacking content there, feel free to help out with a sentence or more!) there from them. It doesn’t make sense to split the effort, so I offered to share the page with DFly.
RealPlayer: Shaun, the FreeBSD maintainer of the helixplayer port, promised to polish up a patchset when he gets time to port helixplayer to a more recent version and send it to the corresponding helix community (requested by some people at Real after showing them the patches via cvsweb). Their review and integration of this stuff will help in getting a RealPlayer binary from Real.
Sound: The work of Ariff (and every other contributor) in the HDA area seems to be very appreciated. There are aven voices asking for a MFC. I don’t think we will get it for 6.2. It’s too late in the release process and Ariff seems to be busy.
Sound2: Ryan committed a fix to P4 which should provide some missing stuff to some breaking ports. If someone has time to commit it…
Linux: A lot of progress happened here. The longstanding major bug on amd64 is fixed and MFCed (thanks to kib!), so we finally got some results for the amd64 runs of the LTP testcases (now color coded to spot problems much faster). The status of the stable run is already on the wiki page (but this is without the MFC). Runs on current (2.4.2 and 2.6.16 based emulation) and stable after the MFC where already done, but I didn’t got time to wiki-fy their status yet.
Ports: I already have an update for my sylpheed-claws port to 2.6.0 together with a move to LOCALBASE (including the plugin ports) available, but I have to wait until the ports–slush is lifted.