On Thu, Oct 27, 2011 at 9:06 PM, Markus Grabner <grabner@xxxxxxxxxxxxx> wrote: > On Thursday 27 October 2011 11:43:21 you wrote: >> On Thu, Oct 27, 2011 at 10:05 AM, Greg KH <gregkh@xxxxxxx> wrote: >> > On Thu, Oct 27, 2011 at 09:28:59AM +0100, Stefan Hajnoczi wrote: >> >> What is the status of the line6 staging driver? There is no TODO file >> >> so I'm not sure what is blocking it from leaving staging. >> > >> > That's a good question. I don't really know the status of the driver at >> > the moment, does anyone else? >> >> I have one question about the design of the driver: >> >> Do we really need the sysfs attributes which boil down to MIDI >> commands? I think a userspace library provides a better interface >> because the MIDI commands/values vary between device models and bloat >> the driver. Generic sound recording and MIDI software would talk to >> the driver. Utilities to control the device could link against the >> userspace library. >> >> By splitting the code into the kernel MIDI/pcm driver and a userspace >> control library which uses MIDI we can slim down the kernel driver and >> leave the large variation of MIDI commands/values to a library that >> the community can improve for specific device models. >> >> This will make the driver smaller and easier for review. > I actually already started to work on this, but progress is slow since I'm > quite busy with other things. As soon as there is a convenient way to access > device parameters via user space code, I agree that the corresponding sysfs > attributes should be removed from the driver. I am working on Pod HD300 support. Because this device doesn't support all MIDI messages that previous models do I am eager to eliminate the hardcoded MIDI messages in the driver. Do you have a development git tree that I could send patches against? The current issue with Pod HD300 is that 48 kHz S24_3LE pcm does not work reliably. gnome-sound-recorder and audacity can record and playback using the device, captured audio is in tune. However after some time recording the sound suddenly changes - almost like the sampling rate has been changed, so everything is high-pitch and tinny. Another symptom is that audacity simply freezes up its GUI and stops recording. I'm still trying to figure out the cause for this pcm capture problem with the following in syslog: pulseaudio[3342]: [alsa-sink] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! pulseaudio[3342]: [alsa-sink] alsa-sink.c: Most likely this is a bug in the ALSA driver 'line6usb'. Please report this issue to the ALSA developers. pulseaudio[3342]: [alsa-sink] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. pulseaudio[3342]: [alsa-sink] alsa-util.c: Could not recover from POLLERR|POLLNVAL|POLLHUP with snd_pcm_prepare(): File descriptor in bad state and pulseaudio[3342]: [alsa-sink] protocol-native.c: Failed to push data into queue It's probably my changes that have broken the driver but are you aware of any existing pcm stability issues with gnome-sound-recorder, audacity, or ardour2 (jack)? Stefan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
