[PATCH] Make channels 3+4 of US428 work

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] Make channels 3+4 of US428 work

Karsten Wiese
Hi Rui

Finally found how to make this tick with mainline jack :-)
please apply.

   Thanks,
   Karsten

jack-usx2y-US428-ch3+4.patch (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Make channels 3+4 of US428 work

Rui Nuno Capela
Karsten,

>
> Finally found how to make this tick with mainline jack :-)
> please apply.
>

ACK.

>
> Make channels 3+4 of US428 work.
>
> This is done by hacking driver->capture_interleave_skip
> in usx2y_driver_start().
> Other changes in usx2y.c improve rawusb mode debugging.
>

OK, although I don't have a US-428 to certify this patch myself. I do only
have a US-224 which has only 2 capture channels, so this one won't make a
difference to me.

Can I ask what's the perceived behavior while using the 3rd and 4th
capture channels on a US-428 without this change? Just curious.


>
> Also in this patch is an unrelated "if (unlikely(x))"
> optimization commonly found in kernel code.
> Here it is applied to alsa_driver_run_cycle().
> This has been proposed by Lee Revel.
>

I do seem to find this one optimization somewhat overzealous, but looks
fair enough. IIRC it's supposed for branch-prediction optimization, and
it's pretty GCC-centric, isn't it? Does it look any better using something
like the this, while on jack/internal.h ?

  #ifdef __GNUC__
  #   define likely(x)     __builtin_expect((x),1)
  #   define unlikely(x)   __builtin_expect((x),0)
  #else
  #   define likely(x)     (x)
  #   define unlikely(x)   (x)
  #endif

Maybe it's just me who's overreacting :)

That said, and if no one stands obviously against, I predict to apply this
soon.

Cheers.
--
rncbc aka Rui Nuno Capela
[hidden email]



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Make channels 3+4 of US428 work

Karsten Wiese
Am Montag, 22. August 2005 16:11 schrieb Rui Nuno Capela:
>
> Can I ask what's the perceived behavior while using the 3rd and 4th
> capture channels on a US-428 without this change? Just curious.

All channels capture data becomes scrambled,
because the frame sequence is wrong then.
 

> I do seem to find this one optimization somewhat overzealous, but looks
> fair enough. IIRC it's supposed for branch-prediction optimization, and
> it's pretty GCC-centric, isn't it? Does it look any better using something
> like the this, while on jack/internal.h ?
>
>   #ifdef __GNUC__
>   #   define likely(x)     __builtin_expect((x),1)
>   #   define unlikely(x)   __builtin_expect((x),0)
>   #else
>   #   define likely(x)     (x)
>   #   define unlikely(x)   (x)
>   #endif
>

Fine with me.

   Best regards,
   Karsten

       

       
               
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Make channels 3+4 of US428 work

Rui Nuno Capela
Karsten,

>>
>> Can I ask what's the perceived behavior while using the 3rd and 4th
>> capture channels on a US-428 without this change? Just curious.
>
> All channels capture data becomes scrambled,
> because the frame sequence is wrong then.
>

Are you just saying that all audio capture on the US-428 has been
scrambled ever since, or just for channels 3 and 4 ?

My US-224 records just fine for quite some time ;) but then again, it only
has 2 input channels.

--
rncbc aka Rui Nuno Capela
[hidden email]



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Make channels 3+4 of US428 work

Jack O'Quin-2
In reply to this post by Rui Nuno Capela
"Rui Nuno Capela" <[hidden email]> writes:

>> Also in this patch is an unrelated "if (unlikely(x))"
>> optimization commonly found in kernel code.
>> Here it is applied to alsa_driver_run_cycle().
>> This has been proposed by Lee Revel.
>
> I do seem to find this one optimization somewhat overzealous, but looks
> fair enough. IIRC it's supposed for branch-prediction optimization, and
> it's pretty GCC-centric, isn't it? Does it look any better using something
> like the this, while on jack/internal.h ?
>
>   #ifdef __GNUC__
>   #   define likely(x)     __builtin_expect((x),1)
>   #   define unlikely(x)   __builtin_expect((x),0)
>   #else
>   #   define likely(x)     (x)
>   #   define unlikely(x)   (x)
>   #endif
>
> Maybe it's just me who's overreacting :)

I think you're right.  Most JACK platforms use GCC, so the
optimization presumably helps (a little) for many users.  But, we
certainly ought not limit JACK to a single compiler.

It would not bother me to leave out the likely(), unlikely()
optimization entirely.  Does it make a measurable difference in the
JACK cycle time?
--
  joq


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Make channels 3+4 of US428 work

Karsten Wiese
In reply to this post by Rui Nuno Capela
Am Montag, 22. August 2005 17:43 schrieb Rui Nuno Capela:

> Karsten,
>
> >>
> >> Can I ask what's the perceived behavior while using the 3rd and 4th
> >> capture channels on a US-428 without this change? Just curious.
> >
> > All channels capture data becomes scrambled,
> > because the frame sequence is wrong then.
> >
>
> Are you just saying that all audio capture on the US-428 has been
> scrambled ever since, or just for channels 3 and 4 ?

Yes, all audio with 4ins active @us428 using official jack.
With only 2ins active it was/is ok.
my version (that didn't make it into cvs cause of doubling too much code)
always worked as it told alsa "i have 2in channels" also when 4ins were active.
When you put your usx2y version into cvs, I had already forgotten,
why it was necessary to pretend to alsa "there are only 2ins" and since there wasn't
that much interest in us428 (and I had my version working) i didn't dig through
to the cause again.....until yesterday.
>
> My US-224 records just fine for quite some time ;) but then again, it only
> has 2 input channels.
>
Fine :-)

       

       
               
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Make channels 3+4 of US428 work

Karsten Wiese
In reply to this post by Jack O'Quin-2
Am Montag, 22. August 2005 17:45 schrieb Jack O'Quin:

> "Rui Nuno Capela" <[hidden email]> writes:
>
> >> Also in this patch is an unrelated "if (unlikely(x))"
> >> optimization commonly found in kernel code.
> >> Here it is applied to alsa_driver_run_cycle().
> >> This has been proposed by Lee Revel.
> >
> > I do seem to find this one optimization somewhat overzealous, but looks
> > fair enough. IIRC it's supposed for branch-prediction optimization, and
> > it's pretty GCC-centric, isn't it? Does it look any better using something
> > like the this, while on jack/internal.h ?
> >
> >   #ifdef __GNUC__
> >   #   define likely(x)     __builtin_expect((x),1)
> >   #   define unlikely(x)   __builtin_expect((x),0)
> >   #else
> >   #   define likely(x)     (x)
> >   #   define unlikely(x)   (x)
> >   #endif
> >
> > Maybe it's just me who's overreacting :)
>
> I think you're right.  Most JACK platforms use GCC, so the
> optimization presumably helps (a little) for many users.  But, we
> certainly ought not limit JACK to a single compiler.
>
> It would not bother me to leave out the likely(), unlikely()
> optimization entirely.  Does it make a measurable difference in the
> JACK cycle time?

Not really measurable here. So just leave it out Rui.

   Cheers,
   Karsten

       

       
               
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Make channels 3+4 of US428 work

Rui Nuno Capela
>>
>> It would not bother me to leave out the likely(), unlikely()
>> optimization entirely.  Does it make a measurable difference in the
>> JACK cycle time?
>
> Not really measurable here. So just leave it out Rui.
>

Too late ;)

--
rncbc aka Rui Nuno Capela
[hidden email]



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel