Hi,
Well - the latest is now out. I thought I would do something different, and comment on the older version.

My comments - well - take them as you will..

Some have decried ubuntu for the lack of configuration tools - to change things the way they want. Hmm. This is "important" to some, but I see a computer as a work tool - something to pick up and use and get the job done. In my experience, "tweaking" the look almost invariably leads to zero productivity improvement, and much wasted time. Some teaks do work::decreasing the size of tool bar, adding a cpu performance meter. To me - I am happy with the "look".

The update manager seriously annoys me. Some packages hang in the install process, doing nothing. You have to open the extra details, click q in the "less" process that is running and trying to explain something, and move on. If linux is truly ready for the
masses, there should be no need for this.

Pulse annoys me. Pulse is designed around one sound device - which means that on a laptop with an inbuilt sound card, and usb headset, only one is operational. True - one can go into the preferences and move the sound to the headset from the sound card. But it is clunky. Would it not be better to make the ring tone playable on the speaker, and the conversation on the headset. Well - some say - you can edit asound.conf with this wonderful short script to get sound that way with alsa. The moment you say, "edit a system sound file", you are proving linux is not ready for the masses.

Alsa annoys me - applications that are labelled "alsa compliant" do not always work.. A customer asked me to write a linux app that has 20 concurrent sound channels on it. On pulse - it runs fine. On Alsa - well - it depends. There is now a document that says some alsa calls are safe for application developers to use - and others that are not safe. Going further, they say that the application should write the sound data to the library in sizes appropriate to the device - so some want it in 16 or 32 or 200 bytes at a time. All applications for alsa have to do this - which means there is a whole lot of duplicated code out there. Surely, such bundling of bytes into the right size is best done in the library? (That is the purpose of a library - to put common code in the one place, accessible to all).

The transition of Alsa to Pulse is the right transition - the process is just painful. Usually hindered by the mountains of legacy alsa scripts we have written to get sound somewhat right. Remember that the only thing which is advanced in alsa is found in the name.

But what really bites, and really annoys, is the handling of USB devices. This problem is also found on Fedora, so don't get excited. I have a USB device which encodes/decodes audio (320 bytes of 8khz audio can be turned into 49 bits). If this device is in the box, the box is then powered on, the usb device does not respond to programming requests. It shows up at /dev/ttyUSBx - the codec connects to linux via a FTDI chip. To get the device to work, it has to be unplugged, and plugged in after power up. --turns out there are a host of other devices (usb mouse etc) out there with a similar problem. Always - they need to be unplugged after boot, and then plugged back in, before they will work. Turns out that there is a thing called a modem-manager, which actively probes all FTDI devices at startup. Yes, I wrote a program to do a FTDI reset in an endeavour to bring it back, and copied/tried the programs out there to reset the usb bus. None of those brought my USB device back to life. So why don't I want to just remove the modem-manager (responsible for mobile broadband wireless)? Well, I could. It would be problem solved (for me). But for others who use my program - they too would have to do the same. And some of them are mobile people, and want the modem-manager. Instead, they all have to remember to unplug/plug the USB device in, and then start my program, and then start work. A process they have to go through every time they boot their box.

Partly the problems results from multiple people using the same vendor_id:product_id on different different devices.

Enough ranting. Maybe this can spark some activity on this list. Who knows - I might get lucky and someone tells me how to disable the modem-manager for a particular usb vendor/product pair.

Cheers,
 Derek.

--
Derek J Smithies Ph.D.
Christchurch,
New Zealand

     -- "How did you make it work??"  "the usual, got everything right"

_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users

Reply via email to