summaryrefslogtreecommitdiffstats
path: root/sound/pci/emu10k1/emupcm.c
Commit message (Collapse)AuthorAgeFilesLines
* ALSA: emu10k1: rework copyright statementsOswald Buddenhagen2023-07-171-1/+4
| | | | | | | | | | | | | | - Remove the "log-like" parts, following the same logic as the previous commit - Unify format - Add missing major contributors, including myself - Sort entries in order of first contribution (Creative comes last for optical reasons; they don't appear to have directly contributed anyway) Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230715160839.326978-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: clean up driver status commentsOswald Buddenhagen2023-07-171-6/+0
| | | | | | | | | | | | | | Empty BUGS and TODO sections don't really help anyone, so remove them. Version information is chronically outdated, and not really useful in a git world anyway, so remove it as well. Also remove duplicated (and outdated, of course) status section from p16v.h (the one in p16v.c is in better shape). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230715160839.326978-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: remove superfluous IRQ enable state savingOswald Buddenhagen2023-07-131-4/+2
| | | | | | | | | | | | | | | | | | | | The mixer, PCM prepare, MIDI, synth driver, and procfs callbacks are all always invoked with IRQs enabled, so there is no point in saving the state. snd_emu1010_load_firmware_entry() is called from emu1010_firmware_work() and snd_emu10k1_emu1010_init(); the latter from snd_emu10k1_create() and snd_emu10k1_resume(), all of which have IRQs enabled. The voice and memory functions are called from mixed contexts, so they keep the state saving. The low-level functions all keep the state saving, because it's not feasible to keep track of what is called where. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230712145750.125086-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: add support for 12 kHz capture on AudigyOswald Buddenhagen2023-06-131-2/+13
| | | | | | | | Fixes a tentative FIXME. Because we can. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-9-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: fix sample rates for E-MU cards at 44.1 kHz word clockOswald Buddenhagen2023-06-131-57/+55
| | | | | | | | | | | Now that we know the actual word clock, we can: - Put the resulting rate into the hardware info - At 44.1 kHz word clock shift the rate for the pitch calculations, which presume a 48 kHz word clock Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-5-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: split off E-MU fallback clock from clock sourceOswald Buddenhagen2023-06-131-2/+2
| | | | | | | | | | | | | | | | So far, we set the fallback as a side effect of setting the source. But the fallback makes no sense at all when an internal clock is selected. Defaulting to 48k for S/PDIF & ADAT makes sense, but as that is the global default and we're not changing it automatically any more, it's just fine to leave it entirely to the explicit setting. This changes the name of the pre-existing control to something more appropriate (regardless of the split), so users will need to adjust their mixer settings. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: fix multi-channel capture config for E-MU cardsOswald Buddenhagen2023-05-241-44/+32
| | | | | | | | | | | | | | On SB cards the number of captured channels is derived from the voice mask mixer control. But for E-MU cards this wasn't actually "wired up", so changing the mask would simply mess up the recording. We could fix that, but the channel routing through the FPGA makes the masking redundant. So instead we hide the control, and let the user specify the PCM channel count the traditional way. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230523200709.236059-5-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: don't restrict capture channel count to powers of twoOswald Buddenhagen2023-05-241-8/+19
| | | | | | | | | | | | | The hardware can deal with primes up to 7 and power-of-two multiples thereof; the limitation is reflected by the possible buffer sizes. Note that setting the voice mask will not allow more than 16 channels even on Sound Blaster Audigy anymore, as 32 seems a bit excessive (the code overall appears to think so, just not in this case). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230523200709.236059-4-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: fix support for 24 kHz captureOswald Buddenhagen2023-05-241-1/+1
| | | | | | | | | | | We need to specify that the hardware supports non-standard rates, as otherwise the sound core creates a constraint which limits the rate to the specified standard rates. That also made the rate constraint we were already adding meaningless. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230523200709.236059-3-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: fix capture buffer size confusionOswald Buddenhagen2023-05-241-7/+10
| | | | | | | | | | | The buffer size register sets the size of the whole buffer, not just one period. We actually handled it like that, except that the constraint was set on the wrong parameter. The period size is implicitly constrained by the buffer size and the fixed period count of 2. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230523200709.236059-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: make channel count of multi-channel playback flexibleOswald Buddenhagen2023-05-241-9/+9
| | | | | | | | There is no reason to nail it to 16 channels. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230523200709.236023-4-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: add synchronized start of multi-channel playbackOswald Buddenhagen2023-05-241-18/+82
| | | | | | | | | | | | | | We use independent voices for the channels, so we need to make an effort to ensure that they are actually in sync. The hardware doesn't provide atomicity, so we may need to retry a few times, due to NMIs, PCI contention, and the wrong phase of the moon. Solution inspired by kX-project. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230523200709.236023-3-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: don't limit multi-channel playback to two periodsOswald Buddenhagen2023-05-241-4/+5
| | | | | | | | | | | | | | For unclear reasons, the extra voice was set up with half the buffer size instead of the period size. Commit 27ae958cf6 ("emu10k1 driver - add multichannel device hw:x,3 [2-8/8]") mentions half-loop interrupts, so maybe this was an artifact of an earlier iteration of the patch. While at it, also fix periods_min of the regular playback - one period makes just no sense. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230523200709.236023-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: pass raw FX send config to snd_emu10k1_pcm_init_voice()Oswald Buddenhagen2023-05-231-30/+24
| | | | | | | | | ... instead of passing in a high-level mixer struct. Let the higher-level functions handle the differences between the voice types. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230523104612.198884-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: introduce higher-level voice manipulation functionsOswald Buddenhagen2023-05-231-17/+53
| | | | | | | | | | This adds snd_emu10k1_pcm_init_{voices,extra_voice}() and snd_emu10k1_playback_{un,}mute_voices() to slightly abstract by voice function and potential stereo property. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230523104612.198884-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: revamp playback voice allocatorOswald Buddenhagen2023-05-201-21/+23
| | | | | | | | | | | | | | | Instead of separate voices, we now allocate non-interleaved channels, which may in turn contain two interleaved voices each. The higher-level code keeps only one pointer per channel. The channels are not allocated in one block any more, as there is no reason to do that. As a consequence of that, and because it is cleaner regardless, we now let the allocator store these pointers at a specified location, rather than returning only the first one and having the calling code deduce the remaining ones. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230518140947.3725394-8-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: make snd_emu10k1_voice_alloc() assign voices' epcmOswald Buddenhagen2023-05-201-5/+2
| | | | | | | | | | The voice allocator clearly knows about the field (it resets it), so it's more consistent (and leads to less duplicated code) to have the constructor take it as a parameter. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230518140947.3725394-7-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: centralize freeing PCM voicesOswald Buddenhagen2023-05-201-15/+13
| | | | | | | | This saves some code duplication; no functional change. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230519184122.3808185-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: make freeing untouched playback voices cheapOswald Buddenhagen2023-05-181-11/+2
| | | | | | | | | | This allows us to drop the code that tries to preserve already allocated voices upon repeated hw_param callback invocations. Getting it right for multi-channel voices would otherwise get a bit hairy. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230518140947.3725394-5-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: improve voice status display in /procOswald Buddenhagen2023-05-181-1/+1
| | | | | | | | | | | | | | | Eliminate the MIDI type, as there is no such thing - the MPU401 port doesn't have anything to do with voices. For clarity, differentiate between regular and extra voices. Don't atomize the enum into bits in the table display. Simplify/optimize the storage. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230518140947.3725394-4-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: enable bit-exact playback, part 4: send amountsOswald Buddenhagen2023-05-181-0/+17
| | | | | | | | | | | | | | | | | On Audigy, the send amounts are merely targets, presumably to avoid sound distortion due to sudden changes, which the EMU8K docu explicitly warns about. However, that "soft-start" would prevent bit-for-bit reproduction, so we now force the current send amounts to their final values at PCM playback init. One might want to do that for the MIDI synthesizer as well, though it seems mostly pointless due to the attack phase each note has anyway. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230518140339.3722279-3-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: enable bit-exact playback, part 3: pitchOswald Buddenhagen2023-05-181-4/+13
| | | | | | | | | | | | | | | | | CPF_CURRENTPITCH starts swerving towards PTRX_PITCHTARGET as soon as that is set. In practice this means that CPF_FRACADDRESS may acquire a non-zero value before we manage to force CPF_CURRENTPITCH to the final value, which would prevent bit-for-bit reproduction. To avoid that this state persists, we now reset CPF_FRACADDRESS when setting CPF_CURRENTPITCH, and to (mostly) avoid that it progresses too far in the first place (possibly even reaching CCCA_CURRADDR), we write PTRX and CPF in one critical section (though NMIs, etc. still make this unreliable). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230518140339.3722279-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: introduce and use snd_emu10k1_ptr_write_multiple()Oswald Buddenhagen2023-05-181-51/+57
| | | | | | | | | | | | While this nicely denoises the code, the real intent is being able to write many registers pseudo-atomically, which will come in handy later. Idea stolen from kX-project. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230518093134.3697955-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: fix PCM playback buffer size constraintsOswald Buddenhagen2023-05-181-12/+26
| | | | | | | | | | | | | | | | | | | The period_bytes_min parameter and the buffer_bytes minimum constraint made no sense at all, as they didn't reflect any hardware limitation. Instead, apply a frame-based period_size minimum constraint, which is derived from the cache size (it would be actually possible to go below that, but it would require special handling, and it would be practically impossible to keep up with the IRQ rate anyway). Sync up the constraints of the EFX playback with those of the regular playback, as there is no reason for them to diverge. N.b., the maximum buffer size is actually arbitrary - the hardware could go waay beyond 128 KiB. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230518092224.3696958-9-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: refactor PCM playback address handlingOswald Buddenhagen2023-05-181-29/+52
| | | | | | | | | | Pull the special handling of extra voices out of snd_emu10k1_pcm_init_voice(), simplify snd_emu10k1_playback_pointer(), and make the logic overall clearer. Also, add verbose comments. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-9-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: refactor PCM playback cache fillingOswald Buddenhagen2023-05-181-12/+21
| | | | | | | | | | | Rename snd_emu10k1_playback_invalidate_cache() to the more apt snd_emu10k1_playback_fill_cache(), and factor out snd_emu10k1_playback_prepare_voices(), which calls the former for all channels. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-8-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: improve API of low-level voice manipulation functionsOswald Buddenhagen2023-05-181-28/+22
| | | | | | | | | | | | | | | | | | Originally, there was a 1:1 relationship between the PCM streams' and the low-level voices' parameters. The addition of multi-channel playback partially invalidated that, but didn't introduce proper layering, so things kept working only by virtue of the multi-channel device never having two channels (yet). The upcoming addition of 32-bit playback would complete upending the relationships. So this patch detaches the low-level parameters from the high-level ones: we pass pre-calculated bit width and stereo flags to the low-level manipulation functions instead of calculating them in-place from the stream parameters. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-7-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: fix PCM playback cache and interrupt handlingOswald Buddenhagen2023-05-181-44/+23
| | | | | | | | | | | | | The cache causes a fixed delay regardless of stream parameters. Consequently, all that "cache invalidate size" calculation stuff was garbage (which can be traced right back to Creative's OSS driver). This also removes the definitions of registers CD1..CDF, because they are accessed only relative to CD0 anyway. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-5-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: skip pointless cache setup for extra voicesOswald Buddenhagen2023-05-181-6/+5
| | | | | | | | | | Given that the data is going to be ignored anyway, and that the cache does not influence interrupt timing (which is the purpose of the extra voices), it's pointless to pre-fill the cache. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-4-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: remove pointless displacement of the extra voicesOswald Buddenhagen2023-05-181-4/+0
| | | | | | | | | | | The idea is to make the extra voice lag behind the "real" voices, but moving the buffer address around doesn't contribute to that, as the CCCA write below uses the same address. The exact address is unimportant, as the data is discarded anyway. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-3-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Revert "ALSA: emu10k1 - delay the PCM interrupts (add pcm_irq_delay parameter)"Oswald Buddenhagen2023-05-181-23/+2
| | | | | | | | | | | This workaround fails to address the underlying problem, which is actually wholly self-made. Subsequent patches will fix it. This reverts commit 56385a12d9bb9e173751f74b6c430742018cafc0. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: pass frame instead of byte addressesOswald Buddenhagen2023-05-181-22/+9
| | | | | | | | | ... to snd_emu10k1_pcm_init_voice(). This makes the code arguably less convoluted. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230517174256.3657060-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: factor out snd_emu10k1_compose_audigy_sendamounts()Oswald Buddenhagen2023-05-171-4/+1
| | | | | | | | Saves a bit of code duplication. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536451-7-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: skip needless setting of some voice registersOswald Buddenhagen2023-05-171-41/+48
| | | | | | | | | | | | | | | | | | | | | | Many registers are meaningless for stereo slaves and the extra voices. This patch cleans up these unnecessary register writes. snd_emu10k1_playback_{trigger,stop}_voice() is not called for stereo slaves any more. snd_emu10k1_playback_prepare_voice() is renamed to snd_emu10k1_playback_unmute_voice(), as this better reflects its remaining function. It's not called for the extra voices any more. Accordingly, snd_emu10k1_playback_mute_voice() is factored out from snd_emu10k1_playback_stop_voice(), and is called selectively as well. This doesn't add conditionals which would avoid initializing sub-registers, as that wouldn't pull its weight. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536451-6-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: rewire {en,dis}abling interrupts for PCM playbackOswald Buddenhagen2023-05-171-16/+29
| | | | | | | | | | | | | | | | | | | We now enable ints even before triggering, and disable them only after stopping - otherwise there is a race condition we may plausibly run into when we pause/resume near the end of the buffer. Updating the epcm->running flag is moved the same way, as it affects the *_pointer() functions, which are called by the interrupt handler. Also, factor these out to own functions, for clarity. For multi-channel, the extra voice is now triggered after all regular voices - we wouldn't want to receive an int before all channels have passed the period boundary. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536451-5-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: remove useless resets of stop-on-loop-end bitsOswald Buddenhagen2023-05-171-1/+0
| | | | | | | | | We initialize them at card init and don't touch them later, so there is no need to reset them again at voice start. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536451-4-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: cleanup envelope register initOswald Buddenhagen2023-05-171-32/+10
| | | | | | | | | | | | | We (rightfully) don't enable the envelope engine for PCM voices, so any related setup is entirely pointless - the EMU8K documentation makes that very clear, and the fact that the various open drivers all use different values to no observable detriment pretty much confirms it. The remaining initializations are regrouped for clarity. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536451-3-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: straighten out FX send initOswald Buddenhagen2023-05-171-8/+6
| | | | | | | | | | | | | | | | | | | | | | | | | The mixer structures were filled in two places: on driver init, and when the devices are opened. The latter made the former pointless, so we remove the former. This implies that mixer dumps may now return all zeroes, which is OK, as restoring them is meaningless as well. Things were even weirder for the (generally unused) secondary sends: Some of the initialization loops were forgotten when support for Audigy was added, thus creating the technically illegal state of multiple sends being routed to the same FX accumulator (though it apparently doesn't matter when the amount is zero). The global multi-channel init used some rather bizarre values for the secondary sends, and the init on open actually forgot to re-initialize them. We now use a not really more useful, but simpler formula. The direct register init was also bogus. This doesn't really matter, as the value is overwritten when a voice comes into use, but still. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230516093612.3536451-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: enable bit-exact playback, part 2: voice attenuationOswald Buddenhagen2023-05-161-2/+2
| | | | | | | | | | | | | | | | | | | | The voice volume is a raw fractional multiplier that can't actually represent 1.0. To still enable real pass-through, we now set the volume to 0.5 (which results in no loss of precision, as the FX bus provides fractional values) and scale up the samples in DSP code. To maintain backwards compatibility with existing configuration files, we rescale the values in the mixer controls. The range is extended upwards from 0xffff to 0x1fffd, which actually introduces the possibility of specifying an amplification. There is still a minor incompatibility with user space, namely if someone loaded custom DSP code. They'll just get half the volume, so this doesn't seem like a big deal. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230514170323.3408834-8-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: remove now superfluous mixer lockingOswald Buddenhagen2023-05-081-2/+0
| | | | | | | | | | | | | | | | | Since commit 5bbb1ab5bd ("control: use counting semaphore as write lock for ELEM_WRITE operation"), mixer values have been fully read-write locked. This means that it is now unnecessary to apply any additional locks to values that are accessed solely by mixer callbacks. Values that are read outside mixer callbacks still need write locking. There are no cases of mixer values being written outside mixer callbacks, so no read locks remain in mixer callbacks. Note that the removed locks refer only to the emu data structure, not the card's registers as the lock's name suggests. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230428095941.1706278-7-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: use more existing defines instead of open-coded numbersOswald Buddenhagen2023-04-281-6/+6
| | | | | | | | | | | | Using the *_MASK defines for "maximal value" is debatable. I got the idea from FreeBSD, and it sorta makes sense to me. Some hunks look a bit incomplete, because code that is going to be subsequently removed is not touched here. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230428080732.1697695-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Merge branch 'for-linus' into for-nextTakashi Iwai2023-04-271-5/+9
|\ | | | | | | | | | | | | Merge 6.3-devel branch back in order to apply the more Realtek HD-audio changes cleanly. Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * ALSA: emu10k1: don't create old pass-through playback device on AudigyOswald Buddenhagen2023-04-061-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | It could have never worked, as snd_emu10k1_fx8010_playback_prepare() and snd_emu10k1_fx8010_playback_hw_free() assume the emu10k1 offset for the ETRAM, and the default DSP code includes no handler for it. It also wouldn't make a lot of sense to make it work, as Audigy has an own, much simpler, pass-through mechanism. So just skip creation of the device. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20230405201220.2197938-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * ALSA: emu10k1: fix capture interrupt handler unlinkingOswald Buddenhagen2023-04-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to two copy/pastos, closing the MIC or EFX capture device would make a running ADC capture hang due to unsetting its interrupt handler. In principle, this would have also allowed dereferencing dangling pointers, but we're actually rather thorough at disabling and flushing the ints. While it may sound like one, this actually wasn't a hypothetical bug: PortAudio will open a capture stream at startup (and close it right away) even if not asked to. If the first device is busy, it will just proceed with the next one ... thus killing a concurrent capture. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20230405201220.2197923-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emu10k1: remove some bogus definesOswald Buddenhagen2023-04-231-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Firstly, remove the FXWC_* defines - the comment on FXWC implies that the relevant defines are the (A_)EXTOUT_* ones. It's unclear where this came from - it was in the initial ALSA import, but neither the driver from Creative nor kX-project have these defines. Secondly, remove A_HR, which made plain no sense (was unused, and clashed with FXRT). Amends commit cbb7d8f9b7b ("emu10k1: Update registers defines for the Audigy 2/emu10k2.5"). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230422161021.1143903-5-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emu10k1: comment updatesOswald Buddenhagen2023-04-231-15/+11
| | | | | | | | | | | | | | | | | | | | | | | | Move comments to better locations, de-duplicate, fix/remove incorrect/ outdated ones, add new ones, and unify spacing somewhat. While at it, also add testing credits for Jonathan Dowland (SB Live! Platinum) and myself (E-MU 0404b). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230422161021.1143903-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emu10k1: remove unused emu->pcm_playback_efx_substream fieldOswald Buddenhagen2023-04-221-2/+0
| | | | | | | | | | | | | | | | | | Amends historic commit 27ae958cf6 ("emu10k1 driver - add multichannel device hw:x,3 [2-8/8]"). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230422132430.1057468-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emu10k1: drop redundant snd_emu10k1_efx_playback_pointer()Oswald Buddenhagen2023-04-221-18/+1
| | | | | | | | | | | | | | | | It's just an (outdated) copy of snd_emu10k1_playback_pointer(). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230421141006.1005452-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emu10k1: drop redundant snd_emu10k1_efx_playback_hw_free()Oswald Buddenhagen2023-04-221-31/+1
|/ | | | | | | | | Or actually, replace snd_emu10k1_playback_hw_free() with it, as that is a subset. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230421141006.1005452-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()Tasos Sahanidis2022-09-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The voice allocator sometimes begins allocating from near the end of the array and then wraps around, however snd_emu10k1_pcm_channel_alloc() accesses the newly allocated voices as if it never wrapped around. This results in out of bounds access if the first voice has a high enough index so that first_voice + requested_voice_count > NUM_G (64). The more voices are requested, the more likely it is for this to occur. This was initially discovered using PipeWire, however it can be reproduced by calling aplay multiple times with 16 channels: aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40 index 65 is out of range for type 'snd_emu10k1_voice [64]' CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7 Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010 Call Trace: <TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x3f __ubsan_handle_out_of_bounds.cold+0x44/0x49 snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1] snd_pcm_hw_params+0x29f/0x600 [snd_pcm] snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm] ? exit_to_user_mode_prepare+0x35/0x170 ? do_syscall_64+0x69/0x90 ? syscall_exit_to_user_mode+0x26/0x50 ? do_syscall_64+0x69/0x90 ? exit_to_user_mode_prepare+0x35/0x170 snd_pcm_ioctl+0x27/0x40 [snd_pcm] __x64_sys_ioctl+0x95/0xd0 do_syscall_64+0x5c/0x90 ? do_syscall_64+0x69/0x90 ? do_syscall_64+0x69/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Signed-off-by: Tasos Sahanidis <tasos@tasossah.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/3707dcab-320a-62ff-63c0-73fc201ef756@tasossah.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-07 19:38:19 +0000