Reading regs from the fpga into an int instead of a u32, trivial
fix.
sound/pci/emu10k1/emuproc.c:422:34: warning: incorrect type in argument 3 (different signedness)
sound/pci/emu10k1/emuproc.c:422:34: expected unsigned int [usertype] *value
sound/pci/emu10k1/emuproc.c:422:34: got int *<noident>
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This header file exists only for some hacks to adapt alsa-driver
tree. It's useless for building in the kernel. Let's move a few
lines in it to sound/core.h and remove it.
With this patch, sound/driver.h isn't removed but has just a single
compile warning to include it. This should be really killed in
future.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Notebook.
Description: The .device=0x0008 chips have new, but different EMU32 in/out
channels. Driver updated to make use of these EMU32 channels.
Signed-off-by: James Courtier-Dutton <James@superbug.co.uk>
Signed-off-by: Jaroslav Kysela <perex@suse.cz>
PCM Midlevel,CA0106 driver,EMU10K1/EMU10K2 driver
Fix by Guillaume Chazarain <guichaz@yahoo.fr>:
Some tunables in /proc have a write() function, but as their
permission does not reflect it, it can be confusing to the user.
So here is a patch that corrects the mode of those files. Note that I
have only tested the 'xrun_debug' entry.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
EMU10K1/EMU10K2 driver
Although we can set 44100 as the output rate, the SPDIF can do it, but the Analog output cannot.
The SPDIF has the bug, whereby the Left channel arrives one sample late, so although we don't do any resampling,
it is not good for AC3 non-audio output.
Signed-off-by: James Courtier-Dutton <James@superbug.co.uk>
EMU10K1/EMU10K2 driver
This patch converts the emu10k1 driver to use the card capabilities
structure for some more things.
Not extensively tested but seems to work.
Signed-off-by: Lee Revell <rlrevell@joe-job.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Harvey Harrison