Re: [Jack-Devel] [PATCH JACK1 & JACK2] drivers/alsa/memops.c: Error when source is non-native byte-order float

PrevNext  Index
DateTue, 16 Aug 2011 14:25:56 +0100
From John Rigg <[hidden] at jrigg dot co dot uk>
To[hidden] at lists dot jackaudio dot org
In-Reply-ToGabriel Beddingfield Re: [Jack-Devel] [PATCH JACK1 & JACK2] drivers/alsa/memops.c: Error when source is non-native byte-order float
On Tue, Aug 09, 2011 at 08:26:27PM -0500, Gabriel Beddingfield wrote:
> On 08/09/2011 03:13 PM, John Rigg wrote:
>>> As best as I can tell, these functions are only called if
>>> driver->quirk_bswap is enabled... and it's not enabled for anything as
>>> far as I can tell.  So, another valid option would be to remove this
>
> I stand corrected on this point.  I found the one line of code that  
> allows it to be enabled.
>
>> Interesting. I'm wondering if this would explain why I've never been able
>> to use my RME HDSPe MADI card in floating point mode with jack clients
>> on my x86_64 system. I haven't had time to investigate and have just been
>> using it in integer mode to get it working.
>>
>> I don't actually know what the byte order of the RME card's float output is,
>> but if jack has been getting it wrong that might explain why I was getting
>> very high level noise instead of a legitimate input signal.
>
> If the RME card is using a big-endian floats, then this is very likely  
> the cause.

To follow this up, I contacted RME and they say all their current cards
use little-endian format. I still suspect incorrect byte order is a
possible culprit as the symptoms are what I'd expect if that was happening
(high level noise, many orders of magnitude higher than full scale on the
A-D converter).

BTW playback in floating point mode is fine, it's only capture that's
messed up.

John
PrevNext  Index

1313500969.23840_0.ltw:2,a <20110816132556.GA3200 at localhost0 dot localdomain>