Summary:ASTERISK-03749: [patch] OSS and ALSA channel drivers use wrong endianness.
Reporter:David Woodhouse (dwmw2)Labels:
Date Opened:2005-03-23 06:40:33.000-0600Date Closed:2008-01-15 15:29:43.000-0600
Versions:Frequency of
Environment:Attachments:( 0) endian.patch.txt
( 1) endiancvs.patch.txt
Description:As far as I can tell, we are assuming that AST_FORMAT_SLINEAR is native-endian. We have no way of dealing with non-native-endian slinear samples; not even a conversion routine? However, chan_oss and chan_alsa are both explicitly requesting little-endian samples from the sound hardware. That sounds fairly unhealthy on my Fedora/PPC box.

This fixes the immediate problem; I'm not sure if other similar problems are lurking. For example, I don't immediately see how we handle the endianness of incoming audio/L16 in rtp.c -- shouldn't that be in network order and hence on i386 shouldn't we be swapping it rather than just treating it as AST_FORMAT_SLINEAR? AFAICT ast_rtp_write() isn't capable of _sending_ AST_FORMAT_LINEAR frames.

I wonder if we should remove AST_FORMAT_SLINEAR and replace it with both AST_FORMAT_SLINEAR_BE and AST_FORMAT_SLINEAR_LE ?
Comments:By: Mark Spencer (markster) 2005-03-23 14:39:45.000-0600

This patch does not appear to apply to CVS...

By: David Woodhouse (dwmw2) 2005-03-23 15:45:57.000-0600

Sorry; this one should work.

By: Mark Spencer (markster) 2005-03-23 19:01:47.000-0600

oh, disclaimer status?

By: David Woodhouse (dwmw2) 2005-03-23 19:06:48.000-0600

Disclaimer faxed 2005-03-22 at 14:00 UTC.

By: Mark Spencer (markster) 2005-03-23 19:43:46.000-0600

Added to CVS, thanks!

By: David Woodhouse (dwmw2) 2005-03-23 22:13:42.000-0600

Sorry, could do with an answer on the ancillary question(s). Fixing these two drivers to match the assumption that everything is always native-endian is all very well, since the hardware can actually _do_ that. But now I'm looking at chan_bluetooth, where the hardware _can't_ do that; the data are always little-endian.

My hack for now is to byteswap data on the way to/from the device, but that's not how format conversion should work; we may have _other_ devices which produce or require little-endian samples, and we'd end up swapping twice for no real reason.

I think we really ought to switch to having two separate formats for SLINEAR; either 'native' and 'non-native', or 'little-endian' and 'big-endian'. The former might be a little easier to implement but the latter would probably be cleaner. I can provide a patch which does this, and provide conversion routines, if you agree that it's required.

By: Mark Spencer (markster) 2005-03-23 23:03:25.000-0600

Yes, sorry, rtp, if enabled for sending/receiving linear *should* do it in network byte order.  if you want to submit a patch it will be welcome.  We don't need routines though, we can already use the assume-optimized ntohs and htons functions.

By: Russell Bryant (russell) 2005-03-31 22:17:24.000-0600

fixed in 1.0

By: Digium Subversion (svnbot) 2008-01-15 15:28:25.000-0600

Repository: asterisk
Revision: 5241

U   trunk/channels/chan_alsa.c
U   trunk/channels/chan_oss.c

r5241 | markster | 2008-01-15 15:28:25 -0600 (Tue, 15 Jan 2008) | 2 lines

fix endianness of OSS/Alsa (bug ASTERISK-3749)



By: Digium Subversion (svnbot) 2008-01-15 15:29:43.000-0600

Repository: asterisk
Revision: 5333

U   branches/v1-0/channels/chan_alsa.c
U   branches/v1-0/channels/chan_oss.c

r5333 | russell | 2008-01-15 15:29:43 -0600 (Tue, 15 Jan 2008) | 2 lines

fix endianness (bug ASTERISK-3749)