[alsa-devel] Driver for TerraTec DMX 6Fire USB

Takashi Iwai tiwai at suse.de
Sat Jan 22 17:35:54 CET 2011


At Fri, 21 Jan 2011 12:48:52 +0100,
Torsten Schenk wrote:
> 
> >I found that the recent kernel has linux/ihex.h helper functions. 
> >They might help for simplifying the code. But, this can be done later 
> >as a a clean-up. 
> Yes, I also discovered this helper function, but it supports only some kind of binary ihex format. It did not accept
> the text .ihx files.

OK.

> >> diff -Nur a/sound/usb/6fire/pcm.c b/sound/usb/6fire/pcm.c 
> >> --- a/sound/usb/6fire/pcm.c    1970-01-01 01:00:00.000000000 +0100 
> >> +++ b/sound/usb/6fire/pcm.c    2011-01-20 23:07:24.000000000 +0100 
> >... 
> >> +/* keep next two synced with 
> >> + * FW_EP_W_MAX_PACKET_SIZE[] and RATES_MAX_PACKET_SIZE */ 
> >> +static const int RATES_IN_PACKET_SIZE[] = { 228, 228, 420, 420, 404, 404 }; 
> >> +static const int RATES_OUT_PACKET_SIZE[] = { 228, 228, 420, 420, 604, 604 }; 
> >> +static const int RATES[] = { 44100, 48000, 88200, 96000, 176400, 192000 }; 
> > 
> >Any reason to use capital letters for these? 
> >Because they are const? 
> That was exactly the idea.

Hm, but it's not so common.  Not too annoying as well, though.

> >Why x86-dependent? 
> I thought so because of the firmware stuff. If bit- or byte-order are changed, the firmware uploading might not work. If I figured out the #ifdef stuff for bit and byte order, I will remove this dependency.

But you are decoding in bytes, not in words or so.  Thus the CPU
byte-order doesn't matter.


thanks,

Takashi


More information about the Alsa-devel mailing list