[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