* 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