* staging: line6 driver status @ 2011-10-27 8:28 Stefan Hajnoczi 2011-10-27 9:05 ` Greg KH 0 siblings, 1 reply; 5+ messages in thread From: Stefan Hajnoczi @ 2011-10-27 8:28 UTC (permalink / raw) To: Markus Grabner; +Cc: Mariusz Kozlowski, Greg Kroah-Hartman, devel, linux-kernel 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. Thanks, Stefan ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: staging: line6 driver status 2011-10-27 8:28 staging: line6 driver status Stefan Hajnoczi @ 2011-10-27 9:05 ` Greg KH 2011-10-27 9:43 ` Stefan Hajnoczi 0 siblings, 1 reply; 5+ messages in thread From: Greg KH @ 2011-10-27 9:05 UTC (permalink / raw) To: Stefan Hajnoczi; +Cc: Markus Grabner, devel, linux-kernel 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? thanks, greg k-h ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: staging: line6 driver status 2011-10-27 9:05 ` Greg KH @ 2011-10-27 9:43 ` Stefan Hajnoczi 2011-10-27 20:06 ` Markus Grabner 0 siblings, 1 reply; 5+ messages in thread From: Stefan Hajnoczi @ 2011-10-27 9:43 UTC (permalink / raw) To: Markus Grabner; +Cc: devel, linux-kernel, Greg KH On Thu, Oct 27, 2011 at 10:05 AM, Greg KH <gregkh@suse.de> 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. Stefan ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: staging: line6 driver status 2011-10-27 9:43 ` Stefan Hajnoczi @ 2011-10-27 20:06 ` Markus Grabner 2011-10-27 23:21 ` Stefan Hajnoczi 0 siblings, 1 reply; 5+ messages in thread From: Markus Grabner @ 2011-10-27 20:06 UTC (permalink / raw) To: Stefan Hajnoczi; +Cc: devel, linux-kernel, Greg KH On Thursday 27 October 2011 11:43:21 you wrote: > On Thu, Oct 27, 2011 at 10:05 AM, Greg KH <gregkh@suse.de> 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. Kind regards, Markus -- Markus Grabner Institute for Computer Graphics and Vision Graz University of Technology, Inffeldgasse 16a/II, 8010 Graz, Austria WWW: http://www.icg.tugraz.at/Members/grabner ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: staging: line6 driver status 2011-10-27 20:06 ` Markus Grabner @ 2011-10-27 23:21 ` Stefan Hajnoczi 0 siblings, 0 replies; 5+ messages in thread From: Stefan Hajnoczi @ 2011-10-27 23:21 UTC (permalink / raw) To: Markus Grabner; +Cc: devel, linux-kernel, Greg KH On Thu, Oct 27, 2011 at 9:06 PM, Markus Grabner <grabner@icg.tugraz.at> wrote: > On Thursday 27 October 2011 11:43:21 you wrote: >> On Thu, Oct 27, 2011 at 10:05 AM, Greg KH <gregkh@suse.de> 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-10-27 23:21 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-10-27 8:28 staging: line6 driver status Stefan Hajnoczi 2011-10-27 9:05 ` Greg KH 2011-10-27 9:43 ` Stefan Hajnoczi 2011-10-27 20:06 ` Markus Grabner 2011-10-27 23:21 ` Stefan Hajnoczi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox