[PATCH] emu10k1: various (mostly trivial) small cleanups

[PATCH] emu10k1: various (mostly trivial) small cleanups

[Lee Revell]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

These patches fix a few minor issues with the emu10k1 driver that would
be good to get fixed before the ALSA 1.0.9 release.  All are 100% safe
to apply, they do not change the functionality at all.

emu10k1-improve-device-names.patch: give the subdevices descriptive
names, like "ADC Capture/Standard PCM Playback" instead of "EMU10K1" for
hw:x,0 and "Multichannel Capture/PT Playback" instead of "EMU10K1 EFX"
for hw:x,2.  Now that qjackctl enumerates the devices automatically,
this is a significant usability improvement.

remove-voice-alloc-printk.patch: silence the "BUG (or not enough
voices)" message.  This does not in fact represent a bug; it's a normal
ocurrence when the wavetable synth is in use.

The next two patches add my copyright for adding the multichannel PCM
support to emupcm.c and emumixer.c.

The final patch adds Clemens Ladisch to the copyright on timer.c, rather
than just saying "Copied from similar code by CL".  This has been
bugging me for a while, since I just copied and pasted from the ymfpci
driver & changed the registers.

Signed-Off-By: Lee Revell <rlrevell@joe-job.com>

[-- Attachment #2: emu10k1-improve-device-names.patch --]
[-- Type: text/x-patch, Size: 1615 bytes --]

Index: alsa/alsa-kernel/pci/emu10k1/emupcm.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/emu10k1/emupcm.c,v
retrieving revision 1.42
diff -u -r1.42 emupcm.c
--- alsa/alsa-kernel/pci/emu10k1/emupcm.c	9 Mar 2005 11:12:10 -0000	1.42
+++ alsa/alsa-kernel/pci/emu10k1/emupcm.c	11 Mar 2005 00:13:02 -0000
@@ -1273,7 +1273,7 @@
 
 	pcm->info_flags = 0;
 	pcm->dev_subclass = SNDRV_PCM_SUBCLASS_GENERIC_MIX;
-	strcpy(pcm->name, "EMU10K1");
+	strcpy(pcm->name, "ADC Capture/Standard PCM Playback");
 	emu->pcm = pcm;
 
 	for (substream = pcm->streams[SNDRV_PCM_STREAM_PLAYBACK].substream; substream; substream = substream->next)
@@ -1308,7 +1308,7 @@
 
 	pcm->info_flags = 0;
 	pcm->dev_subclass = SNDRV_PCM_SUBCLASS_GENERIC_MIX;
-	strcpy(pcm->name, "EMU10K1 multichannel EFX");
+	strcpy(pcm->name, "Multichannel Playback");
 	emu->pcm = pcm;
 
 	for (substream = pcm->streams[SNDRV_PCM_STREAM_PLAYBACK].substream; substream; substream = substream->next)
@@ -1357,7 +1357,7 @@
 	snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &snd_emu10k1_capture_mic_ops);
 
 	pcm->info_flags = 0;
-	strcpy(pcm->name, "EMU10K1 MIC");
+	strcpy(pcm->name, "Mic Capture");
 	emu->pcm_mic = pcm;
 
 	snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV, snd_dma_pci_data(emu->pci), 64*1024, 64*1024);
@@ -1695,7 +1695,7 @@
 	snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &snd_emu10k1_capture_efx_ops);
 
 	pcm->info_flags = 0;
-	strcpy(pcm->name, "EMU10K1 EFX");
+	strcpy(pcm->name, "Multichannel Capture/PT Playback");
 	emu->pcm_efx = pcm;
 	if (rpcm)
 		*rpcm = pcm;

[-- Attachment #3: remove-voice-alloc-printk.patch --]
[-- Type: text/x-patch, Size: 674 bytes --]

Index: alsa/alsa-kernel/pci/emu10k1/voice.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/emu10k1/voice.c,v
retrieving revision 1.7
diff -u -r1.7 voice.c
--- alsa/alsa-kernel/pci/emu10k1/voice.c	18 Feb 2005 10:21:10 -0000	1.7
+++ alsa/alsa-kernel/pci/emu10k1/voice.c	11 Mar 2005 05:20:42 -0000
@@ -81,12 +81,8 @@
 		}
 	}
 	
-	if (first_voice == last_voice) {
-		printk("BUG (or not enough voices), number %d, next free %d!\n",
-				number,
-				emu->next_free_voice);
+	if (first_voice == last_voice)
 		return -ENOMEM;
-	}	
 	
 	for (i=0; i < number; i++) {
 		voice = &emu->voices[(first_voice + i) % NUM_G];

[-- Attachment #4: emupcm-copyright-fix.patch --]
[-- Type: text/x-patch, Size: 637 bytes --]

Index: alsa/alsa-kernel/pci/emu10k1/emupcm.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/emu10k1/emupcm.c,v
retrieving revision 1.43
diff -u -r1.43 emupcm.c
--- alsa/alsa-kernel/pci/emu10k1/emupcm.c	11 Mar 2005 16:32:21 -0000	1.43
+++ alsa/alsa-kernel/pci/emu10k1/emupcm.c	12 Mar 2005 20:48:01 -0000
@@ -2,6 +2,7 @@
  *  Copyright (c) by Jaroslav Kysela <perex@suse.cz>
  *                   Creative Labs, Inc.
  *  Routines for control of EMU10K1 chips / PCM routines
+ *  Multichannel PCM support Copyright (c) Lee Revell <rlrevell@joe-job.com>
  *
  *  BUGS:
  *    --

[-- Attachment #5: emumixer-copyright-fix.patch --]
[-- Type: text/x-patch, Size: 646 bytes --]

Index: alsa/alsa-kernel/pci/emu10k1/emumixer.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/emu10k1/emumixer.c,v
retrieving revision 1.30
diff -u -r1.30 emumixer.c
--- alsa/alsa-kernel/pci/emu10k1/emumixer.c	16 Feb 2005 10:25:36 -0000	1.30
+++ alsa/alsa-kernel/pci/emu10k1/emumixer.c	12 Mar 2005 20:50:03 -0000
@@ -3,6 +3,7 @@
  *                   Takashi Iwai <tiwai@suse.de>
  *                   Creative Labs, Inc.
  *  Routines for control of EMU10K1 chips / mixer routines
+ *  Multichannel PCM support Copyright (c) Lee Revell <rlrevell@joe-job.com>
  *
  *  BUGS:
  *    --

[-- Attachment #6: timer-copyright-fix.patch --]
[-- Type: text/x-patch, Size: 645 bytes --]

Index: alsa/alsa-kernel/pci/emu10k1/timer.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/emu10k1/timer.c,v
retrieving revision 1.1
diff -u -r1.1 timer.c
--- alsa/alsa-kernel/pci/emu10k1/timer.c	10 Nov 2004 09:49:12 -0000	1.1
+++ alsa/alsa-kernel/pci/emu10k1/timer.c	12 Mar 2005 20:48:16 -0000
@@ -1,10 +1,8 @@
 /*
  *  Copyright (c) by Lee Revell <rlrevell@joe-job.com>
- *  
+ *                   Clemens Ladisch <clemens@ladisch.de>
  *  Routines for control of EMU10K1 chips
  *
- *  Copied from similar code by Clemens Ladisch in the ymfpci driver
- * 
  *  BUGS:
  *    --
  *

Re: [PATCH] emu10k1: various (mostly trivial) small cleanups

[Jaroslav Kysela]

On Sat, 12 Mar 2005, Lee Revell wrote:

> These patches fix a few minor issues with the emu10k1 driver that would
> be good to get fixed before the ALSA 1.0.9 release.  All are 100% safe
> to apply, they do not change the functionality at all.

Applied.

> remove-voice-alloc-printk.patch: silence the "BUG (or not enough
> voices)" message.  This does not in fact represent a bug; it's a normal
> ocurrence when the wavetable synth is in use.

Note that it might be useful to add some "alloc fail" statistics
(available via the procfs) for debugging.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: [PATCH] emu10k1: various (mostly trivial) small cleanups

[Clemens Ladisch]

Lee Revell wrote:
> timer.c ... I just copied and pasted from the ymfpci driver &
> changed the registers.

BTW: Does the Emu10k1 have some sample/tick counter that runs even if
no PCMs are running?  If so, it would be possible to detect lost timer
interrupts.


Regards,
Clemens



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: [PATCH] emu10k1: various (mostly trivial) small cleanups

[Lee Revell]

On Mon, 2005-03-14 at 09:23 +0100, Clemens Ladisch wrote:
> Lee Revell wrote:
> > timer.c ... I just copied and pasted from the ymfpci driver &
> > changed the registers.
> 
> BTW: Does the Emu10k1 have some sample/tick counter that runs even if
> no PCMs are running?  If so, it would be possible to detect lost timer
> interrupts.
> 

Sure does, it has a wall clock timer.  I used it a lot for debugging
while developing the multichannel support.

Lee



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: [PATCH] emu10k1: various (mostly trivial) small cleanups

[Lee Revell]

On Mon, 2005-03-14 at 09:23 +0100, Clemens Ladisch wrote:
> Lee Revell wrote:
> > timer.c ... I just copied and pasted from the ymfpci driver &
> > changed the registers.
> 
> BTW: Does the Emu10k1 have some sample/tick counter that runs even if
> no PCMs are running?  If so, it would be possible to detect lost timer
> interrupts.

In practice I have found that interrupts are basically never lost.  The
only time I ever saw this happen was when the VIA Unichrome XAA (yep,
userspace!) driver had a FIFO related bug where it would temporarily
stall the PCI bus.

I guess I am wondering whether this would be worth implementing.  Do
you think the overhead of reading the wall clock register on every timer
interrupt is worth it?

Lee




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: [PATCH] emu10k1: various (mostly trivial) small cleanups

[Clemens Ladisch]

Lee Revell wrote:
> On Mon, 2005-03-14 at 09:23 +0100, Clemens Ladisch wrote:
> > BTW: Does the Emu10k1 have some sample/tick counter that runs even if
> > no PCMs are running?  If so, it would be possible to detect lost timer
> > interrupts.
>
> In practice I have found that interrupts are basically never lost.  The
> only time I ever saw this happen was when the VIA Unichrome XAA (yep,
> userspace!) driver had a FIFO related bug where it would temporarily
> stall the PCI bus.

I saw it when ripping audio from CDs with a 2.4 kernels (does not
support DMA in this case).

> I guess I am wondering whether this would be worth implementing.  Do
> you think the overhead of reading the wall clock register on every timer
> interrupt is worth it?

Probably not, when we declare 2.4 obsolete. :)  Drivers that disable
interrupts for too long _are_ considered broken, after all.

I'd think the only case where it's really worth it would be if the
hardware has direct support for this, with a timer overflow counter or
something like this.


Regards,
Clemens



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click