M-Audio FTU remaining mixer controls and external clocking support.

M-Audio FTU remaining mixer controls and external clocking support.

[Aurélien Leblond]

>Yes, sorry for this taking longer than expected. I've been working on
>this for a while and will continue doing so next week. I just got too
>much things to do in parallel these days. I'll get back to you once I
>can show patches for testing.

That's a great news, I'm ready any time for testing!

Aurélien

Re: M-Audio FTU remaining mixer controls and external clocking support.

[Daniel Mack]

On Sat, Aug 20, 2011 at 10:52 AM, Aurélien Leblond <blablack@gmail.com> wrote:
>>Yes, sorry for this taking longer than expected. I've been working on
>>this for a while and will continue doing so next week. I just got too
>>much things to do in parallel these days. I'll get back to you once I
>>can show patches for testing.
>
> That's a great news, I'm ready any time for testing!

So, I've been working on this more or less full-time for a couple of
days now and so it's time for an update. Also, I would like to have
some oppinions before I continue.

I thought a lot about how this can be solved and what I come up with
now is a rather intrusive patch that re-writes the entire streaming
logic of the driver.

First tests show that this approach works quite well, and I actually
also like the new implementation better than the old one. Let me try
and explain the idea.

First off, I moved a bunch of code between the files to have a clearer
picture about which logic resides where. So in particular

- stream.c does the substream setup
- pcm.c cares for everything that is related to pcm (no more
cross-linking between pcm.c and urb.c)
- urb.c was replaced by endpoint.c which holds the logic about
everything that is related to an endpoint

So this last point is actually the major news here. The idea is to
have an entity that knows about an endpoint, which can either carry
audio data or sync data. It knows about its urbs and tracks them, and
is responsible for killing them again eventually. It can have links
(function pointers) to talk to an pcm stream to either let the pcm
logic fill in audio material to urbs (playback case) or lets it parse
audio material from urbs (capture case). It also implements a
refcounting, so an endpoint that is already in use as implicit data
feedback source can be re-used as record source for pcm streams
easily. The first user will start the stream, and only the last one
will tear it down.

So this is the cleanest de-coupling I actually think of right now, but
others might disagree. Hence, I would like to hear some oppinions
about this massive patch. I have a split version of it, but the major
part too intrusive to be split up nicely (at least without added tons
of API-compat code for the transition).

I tested this with an "usual" USB device that features a sync endpoint
as well as with the FTU.

For the FTU, we seem to have another problem which is that the two
endpoints are put into two different interfaces. That causes the code
to call usb_set_interface() once the record stream is opened, and in
case the playback stream is already active, it will stop streaming due
to usb_submit_urb() returning -ENOENT. It's probably easy to fix - any
ideas?

I put the patch online here:

  https://gist.github.com/1168715


Daniel

Re: M-Audio FTU remaining mixer controls and external clocking support.

[Felix Homann]

Hi Daniel!

While I can't comment on the changes you made (my lack of
expertise...) I just want to thank you for this massive work of yours.
I will try the patch on the weekend - right now I'm busy recovering my
main machine from a hard disk crash.

Regards,

Felix

2011/8/24 Daniel Mack <zonque@gmail.com>:
> On Sat, Aug 20, 2011 at 10:52 AM, Aurélien Leblond <blablack@gmail.com> wrote:
>
> So, I've been working on this more or less full-time for a couple of
> days now and so it's time for an update. Also, I would like to have
> some oppinions before I continue. [...]

OT: recovery from hard disk crash (was: M-Audio FTU remaining mixer controls and external clocking support.)

[Paul Menzel]

[-- Attachment #1.1: Type: text/plain, Size: 438 bytes --]

Dear Felix,


Am Donnerstag, den 25.08.2011, 15:08 +0200 schrieb Felix Homann:

[…]

> right now I'm busy recovering my main machine from a hard disk crash.

don’t you have any backups :P. Well, I know it is the wrong answer in
this situation. I can only recommend the Grml live system, which
includes a lot of tools you can use for recovery.


Thanks and good luck with the recovery,

Paul


[1] http://grml.org/

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: M-Audio FTU remaining mixer controls and external clocking support.

[Grant Diffey]

Daniel,

Thanks heaps for all your work.

I'm trying to apply this to stable and having conflicts what's it based
against?

Grant.

On Thu, Aug 25, 2011 at 11:08 PM, Felix Homann <linuxaudio@showlabor.de>wrote:

> Hi Daniel!
>
> While I can't comment on the changes you made (my lack of
> expertise...) I just want to thank you for this massive work of yours.
> I will try the patch on the weekend - right now I'm busy recovering my
> main machine from a hard disk crash.
>
> Regards,
>
> Felix
>
> 2011/8/24 Daniel Mack <zonque@gmail.com>:
> > On Sat, Aug 20, 2011 at 10:52 AM, Aurélien Leblond <blablack@gmail.com>
> wrote:
> >
> > So, I've been working on this more or less full-time for a couple of
> > days now and so it's time for an update. Also, I would like to have
> > some oppinions before I continue. [...]
>

Re: M-Audio FTU remaining mixer controls and external clocking support.

[Daniel Mack]

On Thu, Aug 25, 2011 at 3:25 PM, Grant Diffey <gdiffey@gmail.com> wrote:
> Daniel,
>
> Thanks heaps for all your work.
>
> I'm trying to apply this to stable and having conflicts what's it based
> against?

Takashi's sound-2.6 master branch. I forked from it some days ago.


Daniel

Re: M-Audio FTU remaining mixer controls and external clocking support.

[Daniel Mack]

On Aug 26, 2011 3:35 PM, "Grant Diffey" <gdiffey@gmail.com> wrote:
>
> So on my freshly built 3.1-rc1  this applied cleanly but I'm getting
errors every time I try to open the device. on the FTU.
>
> attempting to start jack gives this in dmesg:
>
> [ 2091.951806] stop_endpoints()
> [ 2197.403224] Re-using EP 81 @ffff880003560000
> [ 2197.403243] attr 4
> [ 2197.403929] stop_endpoints()
> [ 2197.403931]  -- data ffff880003560000
> [ 2197.403933]  -- sync           (null)
> [ 2197.403935] Unable to change format on ep #81: already in use
>
> and hitting play on audacity results in the attached dmesg errors.
>
> is this expected currently?

Can you try to just open either the playback or the capture stream
seperately, and not both at the same time?

Daniel

Re: M-Audio FTU remaining mixer controls and external clocking support.

[Grant Diffey]

On Fri, Aug 26, 2011 at 11:43 PM, Daniel Mack <zonque@gmail.com> wrote:

>
> On Aug 26, 2011 3:35 PM, "Grant Diffey" <gdiffey@gmail.com> wrote:
> >
> > So on my freshly built 3.1-rc1  this applied cleanly but I'm getting
> errors every time I try to open the device. on the FTU.
> >
> > attempting to start jack gives this in dmesg:
> >
> > [ 2091.951806] stop_endpoints()
> > [ 2197.403224] Re-using EP 81 @ffff880003560000
> > [ 2197.403243] attr 4
> > [ 2197.403929] stop_endpoints()
> > [ 2197.403931]  -- data ffff880003560000
> > [ 2197.403933]  -- sync           (null)
> > [ 2197.403935] Unable to change format on ep #81: already in use
> >
> > and hitting play on audacity results in the attached dmesg errors.
> >
> > is this expected currently?
>
> Can you try to just open either the playback or the capture stream
> seperately, and not both at the same time?
>
> Daniel
>

Re: M-Audio FTU remaining mixer controls and external clocking support.

[Daniel Mack]

On Fri, Aug 26, 2011 at 4:06 PM, Grant Diffey <gdiffey@gmail.com> wrote:
> On Fri, Aug 26, 2011 at 11:43 PM, Daniel Mack <zonque@gmail.com> wrote:
>>
>> Can you try to just open either the playback or the capture stream
>> seperately, and not both at the same time?
>
> So...
>
> nevyn@cetacea:~/linux/linux$ aplay -D plughw:Ultra
> /usr/share/sounds/KDE_Startup_new.wav
> Playing WAVE '/usr/share/sounds/KDE_Startup_new.wav' : Signed 16 bit Little
> Endian, Rate 22050 Hz, Stereo
> aplay: set_params:1123: Unable to install hw params:

Hmm? Strange, that worked for me. Does re-plugging the device help
maybe? I can look into this deeper next week.

The patch I sent out was also merely meant to be a base for discussion
about whether the whole approach is sane, or just a result of my head
thinking about it for too long :)

Daniel

Re: M-Audio FTU remaining mixer controls and external clocking support.

[Grant Diffey]

On Sat, Aug 27, 2011 at 12:18 AM, Daniel Mack <zonque@gmail.com> wrote:

> On Fri, Aug 26, 2011 at 4:06 PM, Grant Diffey <gdiffey@gmail.com> wrote:
> > On Fri, Aug 26, 2011 at 11:43 PM, Daniel Mack <zonque@gmail.com> wrote:
> >>
> >> Can you try to just open either the playback or the capture stream
> >> seperately, and not both at the same time?
> >
> > So...
> >
> > nevyn@cetacea:~/linux/linux$ aplay -D plughw:Ultra
> > /usr/share/sounds/KDE_Startup_new.wav
> > Playing WAVE '/usr/share/sounds/KDE_Startup_new.wav' : Signed 16 bit
> Little
> > Endian, Rate 22050 Hz, Stereo
> > aplay: set_params:1123: Unable to install hw params:
>
> Hmm? Strange, that worked for me. Does re-plugging the device help
> maybe? I can look into this deeper next week.
>
> The patch I sent out was also merely meant to be a base for discussion
> about whether the whole approach is sane, or just a result of my head
> thinking about it for too long :)
>
> Daniel
>

So I've just tested again being more awake and yes replugging the device
fixes it.

With regard to the open record while streaming stuff maybe a stream pool
would be a way to aproach it? so you open all the endpoints always and just
dump the data unless there's a pcm stream to attach to but I'm probably way
off.

Grant.