summaryrefslogtreecommitdiffstats
path: root/sound/pci/emu10k1
Commit message (Collapse)AuthorAgeFilesLines
* ALSA: pcm: optimize and clarify stream synchronization ID APIJaroslav Kysela2024-07-021-4/+12
| | | | | | | | | | | | Optimize the memory usage in struct snd_pcm_runtime - use boolean value for the standard sync ID scheme. Introduce snd_pcm_set_sync_per_card function to build synchronization IDs. Signed-off-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240625172836.589380-3-perex@perex.cz
* ALSA: pcm: reinvent the stream synchronization ID APIJaroslav Kysela2024-07-021-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Until the commit e11f0f90a626 ("ALSA: pcm: remove SNDRV_PCM_IOCTL1_INFO internal command"), there was a possibility to pass information about the synchronized streams to the user space. The mentioned commit removed blindly the appropriate code with an irrelevant comment. The revert may be appropriate, but since this API was lost for several years without any complains, it's time to improve it. The hardware parameters may change the used stream clock source (e.g. USB hardware) so move this synchronization ID to hw_params as read-only field. It seems that pipewire can benefit from this API (disable adaptive resampling for perfectly synchronized PCM streams) now. Note that the contents of ID is not supposed to be used for direct comparison with a specific byte sequence. The "empty" case is when all bytes are zero (driver does not offer this information) and all other cases must be only used for equal comparison among PCM streams (including different sound cards) if they are using identical hardware clock. Cc: Takashi Sakamoto <takaswie@kernel.org> Signed-off-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/20240625172836.589380-2-perex@perex.cz
* ALSA: pci: Use *-y instead of *-objs in MakefileTakashi Iwai2024-05-081-3/+3
| | | | | | | | | | | | | *-objs suffix is reserved rather for (user-space) host programs while usually *-y suffix is used for kernel drivers (although *-objs works for that purpose for now). Let's correct the old usages of *-objs in Makefiles. Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20240507135513.14919-3-tiwai@suse.de
* Merge branch 'topic/emu10k1-fix' into for-nextTakashi Iwai2024-04-285-169/+188
|\ | | | | | | | | | | Pull emu10k1 fixes from Oswald Buddenhagen Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * ALSA: emu10k1: move code for entering E-MU card FPGA programming modeOswald Buddenhagen2024-04-282-7/+7
| | | | | | | | | | | | | | | | | | ... into snd_emu1010_load_firmware_entry(). This makes it clearer that these steps belong together tightly, as implied by prior commits. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093717.3198716-5-oswald.buddenhagen@gmx.de>
| * ALSA: emu10k1: move snd_emu1010_load_firmware_entry() to io.cOswald Buddenhagen2024-04-282-41/+48
| | | | | | | | | | | | | | | | | | | | | | | | It is a low-level I/O access function, so io.c is the natural place for it. While we're moving the code, reduce the scope of some variables, use compound assignment operators, and add/adjust some comments. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093717.3198716-4-oswald.buddenhagen@gmx.de>
| * ALSA: emu10k1: make snd_emu1010_load_firmware_entry() voidOswald Buddenhagen2024-04-281-7/+3
| | | | | | | | | | | | | | | | | | There is only one call site, and there we already know that we actually have a firmware. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093717.3198716-3-oswald.buddenhagen@gmx.de>
| * ALSA: emu10k1: simplify E-MU card FPGA reset sequenceOswald Buddenhagen2024-04-281-22/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Firstly, it is pointless to explicitly disable the power to the dock prior to resetting the FPGA, as the latter will do the former anyway. Secondly, it doesn't make much sense to check whether the FPGA is already programmed. It's much simpler to just presume it is, and issue the self-reset command. If it isn't, the effect isn't worse than the checks themselves. As a side effect, we lose the info if the reset fails, but there is no plausible way how that could happen unless the card burns out while operating, and in that case we'll detect a firmware upload failure a bit later anyway. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093717.3198716-2-oswald.buddenhagen@gmx.de>
| * ALSA: emu10k1: make E-MU FPGA writes potentially more reliableOswald Buddenhagen2024-04-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We did not delay after the second strobe signal, so another immediately following access could potentially corrupt the written value. This is a purely speculative fix with no supporting evidence, but after taking out the spinlocks around the writes, it seems plausible that a modern processor could be actually too fast. Also, it's just cleaner to be consistent. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-7-oswald.buddenhagen@gmx.de>
| * ALSA: emu10k1: fix E-MU dock initializationOswald Buddenhagen2024-04-281-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A side effect of making the dock monitoring interrupt-driven was that we'd be very quick to program a freshly connected dock. However, for unclear reasons, the dock does not work when we do that - despite the FPGA netlist upload going just fine. We work around this by adding a delay before programming the dock; for safety, the value is several times as much as was determined empirically. Note that a badly timed dock hot-plug would have triggered the problem even before the referenced commit - but now it would happen 100% instead of about 3% of the time, thus making it impossible to work around by re-plugging. Fixes: fbb64eedf5a3 ("ALSA: emu10k1: make E-MU dock monitoring interrupt-driven") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218584 Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-6-oswald.buddenhagen@gmx.de>
| * ALSA: emu10k1: use mutex for E-MU FPGA access lockingOswald Buddenhagen2024-04-284-37/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FPGA access through the GPIO port does not interfere with other sound processor register access, so there is no need to subject it to emu_lock. And after moving all FPGA access out of the interrupt handler, it does not need to be IRQ-safe, either. What's more, attaching the dock causes a firmware upload, which takes several seconds. We really don't want to disable IRQs for this long, and even less also have someone else spin with IRQs disabled waiting for us. Therefore, use a mutex for FPGA access locking. This makes the code somewhat more noisy, as we need to wrap bigger sections into the mutex, as it needs to enclose the spinlocks. The latter has the "side effect" of fixing dock FPGA programming in a corner case: a really badly timed mixer access right between entering FPGA programming mode and uploading the netlist would mess up the protocol. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-5-oswald.buddenhagen@gmx.de>
| * ALSA: emu10k1: move the whole GPIO event handling to the workqueueOswald Buddenhagen2024-04-282-30/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The actual event processing was already done by workqueue items. We can move the event dispatching there as well, rather than doing it already in the interrupt handler callback. This change has a rather profound "side effect" on the reliability of the FPGA programming: once we enter programming mode, we must not issue any snd_emu1010_fpga_{read,write}() calls until we're done, as these would badly mess up the programming protocol. But exactly that would happen when trying to program the dock, as that triggers GPIO interrupts as a side effect. This is mitigated by deferring the actual interrupt handling, as workqueue items are not re-entrant. To avoid scheduling the dispatcher on non-events, we now explicitly ignore GPIO IRQs triggered by "uninteresting" pins, which happens a lot as a side effect of calling snd_emu1010_fpga_{read,write}(). Fixes: fbb64eedf5a3 ("ALSA: emu10k1: make E-MU dock monitoring interrupt-driven") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218584 Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-4-oswald.buddenhagen@gmx.de>
| * ALSA: emu10k1: factor out snd_emu1010_load_dock_firmware()Oswald Buddenhagen2024-04-281-30/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pulled out of the next patch to improve its legibility. As the function is now available, call it directly from snd_emu10k1_emu1010_init(), thus making the MicroDock firmware loading synchronous - there isn't really a reason not to. Note that this does not affect the AudioDocks of rev1 cards, as these have no independent power supplies, and thus come up only a while after the main card is initialized. As a drive-by, adjust the priorities of two messages to better reflect their impact. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-3-oswald.buddenhagen@gmx.de>
| * ALSA: emu10k1: fix E-MU card dock presence monitoringOswald Buddenhagen2024-04-281-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While there are two separate IRQ status bits for dock attach and detach, the hardware appears to mix them up more or less randomly, making them useless for tracking what actually happened. It is much safer to check the dock status separately and proceed based on that, as the old polling code did. Note that the code assumes that only the dock can be hot-plugged - if other option card bits changed, the logic would break. Fixes: fbb64eedf5a3 ("ALSA: emu10k1: make E-MU dock monitoring interrupt-driven") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218584 Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de> Message-ID: <20240428093716.3198666-2-oswald.buddenhagen@gmx.de>
* | ALSA: emu10k1: shrink blank space in front of wavetable samplesOswald Buddenhagen2024-04-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | There is no need for it to be 32 samples - 3 will do just fine (which is the interpolator's epsilon). The old size was presumably meant to compensate for the cache's presence, but we're now handling that properly. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-17-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emu10k1: fix wavetable playback position and caching, take 2Oswald Buddenhagen2024-04-072-7/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compensate for the cache lag of 64 frames, and actually populate the cache. Without these, the playback would start with garbage (which would be (mostly?) masqueraded by the note's attack phase). Note that we set the starting address only 61 frames ahead, to compensate for the interpolator's epsilon. Unlike for PCM playback, we don't even need to manually silence-fill the first frames in the cache, because we insert some silence in front of each sample anyway. A challenge are extremely short samples with a loop end below the cache size, because a) we'd have to wrap the current address to be within the loop and b) automatic pre-filling of the cache with the right data does not work in this case. We could pre-fill the cache manually, but that's slow, requires additional code for each sample width, and is made even more complex by the driver's virtual address space having no contiguous mapping for the CPU. We could have the engine fill the cache piece-wise (which is really what happens when playback is running), but that would also be complex, and we'd need to wait for the engine to handle each piece, so it wouldn't be that much faster than the manual fill. For the case of requiring only one loop iteration prior to reaching the cache size, we could leverage the engine's looping mechanism around CCR_CACHELOOPFLAG, but this special case doesn't seem worth the complexity. So we just unroll the loop as far as necessary to be able to play back the sample without any fiddling. Pedantically, this would be incorrect for loop-until-release samples with a low loop end which are released very quickly, but that would be relatively harmless, is not a plausible use case in the first place, and SoundFont sample mode 3 isn't actually implemented anyway (it's conflated with mode 1, infinite looping). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-16-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emu10k1: de-duplicate size calculations for 16-bit samplesOswald Buddenhagen2024-04-071-9/+6
| | | | | | | | | | | | | | | | | | Instead of repeatedly checking the sample width, assign a size shift centrally. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-14-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emu10k1: fix wavetable offset recalculationOswald Buddenhagen2024-04-071-10/+6
| | | | | | | | | | | | | | | | | | | | | | The offsets are counted in samples, not in bytes. While the code block is being rewritten, also move it up a bit, to avoid churn in a subsequent patch. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-13-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emu10k1: merge conditions in patch loaderOswald Buddenhagen2024-04-071-9/+7
| | | | | | | | | | | | | | | | | | This de-duplicates the code slightly. But the real reason is that it moves the code up, which the next patch will depend on. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-12-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emu10k1: fix playback of 8-bit wavetable samplesOswald Buddenhagen2024-04-071-2/+4
| | | | | | | | | | | | | | | | | | Samples are byte-sized in this mode, and thus the offset calculation needs no shifting. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-11-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emu10k1: fix sample signedness issues in wavetable loaderOswald Buddenhagen2024-04-072-26/+53
| | | | | | | | | | | | | | | | | | | | | | | | The hardware supports S16LE and U8 samples, while U16LE and S8 (which the driver implicitly claims to support) require sign flipping. Note that this matters only for the GUS patch loader, as the implemented SoundFont v2.01 spec is limited to S16LE. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-10-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emu10k1: move patch loader assertions into low-level functionsOswald Buddenhagen2024-04-072-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | Convert some checks in snd_emu10k1_sample_new() back into assertions (as they were prior to da3cec35dd (ALSA: Kill snd_assert() in sound/pci/*, 2008-08-08)), and move them into the low-level memory access functions they protect. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-9-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emux: centralize & improve patch info validationOswald Buddenhagen2024-04-071-16/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This does several closely related things: - Move the code from the drivers into the SoundFont loader, which de-duplicates it. - Sort of explain the weird "recalculate address offset" feature. Note that I don't think it actually makes any sense - the calling user space code should do that. The background is certainly that the source data (the SoundFont format) uses pointers into a single wave block (and the API allows doing the same for on-board ROM), but the API expects the wave data from user space to be pre-chopped into individual patches anyway. - Make sure that the specified offsets actually lie within the supplied wave data. Note that we don't validate ROM offsets, so one can play back anything within the sound card's address space. - In load_guspatch(), don't call the sample_new callback anymore when the patch size is zero, as was already the case in load_data(). The callbacks would instantly return in that case anyway; these checks are now removed. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-7-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emu10k1: prune vestiges of SNDRV_SFNT_SAMPLE_{BIDIR,REVERSE}_LOOP supportOswald Buddenhagen2024-04-071-65/+8
|/ | | | | | | | | | | | | | | | | | | | | | | This is required only to implement WAVE_BIDIR_LOOP and WAVE_LOOP_BACK in the GUS patch loader. It has not worked on emu10k1 since before ALSA hit mainline, yet nobody appears to have complained. And as it isn't super easy to implement, just admit defeat and clean up the code. If somebody wanted to resurrect the feature, the emu8k driver could serve as a template, but the code would be quite different. But arguably, this should be done in user space in the first place, as this doesn't represent a hardware feature (somewhat ironically, the actual GUS driver has no synth support, and therefore no GUS patch loader). Note that instead of properly rejecting affected samples, we continue to just pretend that the feature wasn't requested. This is extremely questionable behavior, but avoids that possibly unused instruments suddenly prevent loading the entire file, which would break backwards compatibility. But at least we log a warning now. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240406064830.1029573-6-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Revert "ALSA: emu10k1: fix synthesizer sample playback position and caching"Oswald Buddenhagen2024-04-021-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | As already anticipated in the original commit, playback was broken for very short samples. I just didn't expect it to be an actual problem, because we're talking about less than 1.5 milliseconds here. But clearly such wavetable samples do actually exist. The problem was that for such short samples we'd set the current position beyond the end of the loop, so we'd run off the end of the sample and play garbage. This is a bigger (more audible) problem than the original one, which was that we'd start playback with garbage (whatever was still in the cache), which would be mostly masked by the note's attack phase. So revert to the old behavior for now. We'll subsequently fix it properly with a bigger patch series. Note that this isn't a full revert - the dead code is not re-introduced, because that would be silly. Fixes: df335e9a8bcb ("ALSA: emu10k1: fix synthesizer sample playback position and caching") Link: https://bugzilla.kernel.org/show_bug.cgi?id=218625 Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Message-ID: <20240401145805.528794-1-oswald.buddenhagen@gmx.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: Simplify with snd_ctl_find_id_mixer()Takashi Iwai2023-07-211-10/+1
| | | | | | | | Replace an open code with the new snd_ctl_find_id_mixer(). There is no functional change. Link: https://lore.kernel.org/r/20230720082108.31346-5-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Merge tag 'tags/ctl-lock-fixes-6.6' into for-nextTakashi Iwai2023-07-201-5/+0
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ALSA: Make control API taking controls_rwsem consistently A few ALSA control API helpers like snd_ctl_rename(), snd_ctl_remove() and snd_ctl_find_*() suppose the callers taking card->controls_rwsem. But it's error-prone and fragile. This patch set tries to change those API functions to take the card->controls>rwsem internally by themselves, so that the drivers don't need to take care of lockings. After applying this patch set, only a couple of places still touch card->controls_rwsem (which are OK-ish as they need for traversing the control linked list). Link: https://lore.kernel.org/r/20230718141304.1032-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * ALSA: emu10k1: Go back and simplify with snd_ctl_find_id()Takashi Iwai2023-07-201-4/+1
| | | | | | | | | | | | | | | | Now that snd_ctl_find_id() takes the locking itself, we can get rid of the messy locking in the caller side in snd_emu10k1_verify_controls(). Link: https://lore.kernel.org/r/20230718141304.1032-12-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * ALSA: control: Introduce unlocked version for snd_ctl_find_*() helpersTakashi Iwai2023-07-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For reducing the unnecessary use of controls_rwsem in the drivers, this patch adds a new variant for snd_ctl_find_*() helpers: snd_ctl_find_id_locked() and snd_ctl_find_numid_locked() look for a kctl element inside the card->controls_rwsem -- that is, doing the very same as what snd_ctl_find_id() and snd_ctl_find_numid() did until now. snd_ctl_find_id() and snd_ctl_find_numid() remain same, i.e. still unlocked version, but they will be switched to locked version once after all callers are replaced. The patch also replaces the calls of snd_ctl_find_id() and snd_ctl_find_numid() in a few places; all of those are places where we know that the functions are called properly with controls_rwsem held. All others are without rwsem (although they should have been). After this patch, we'll turn on the locking in snd_ctl_find_id() and snd_ctl_find_numid() to be more race-free. Link: https://lore.kernel.org/r/20230718141304.1032-10-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
| * ALSA: control: Take controls_rwsem lock in snd_ctl_remove()Takashi Iwai2023-07-201-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far, snd_ctl_remove() requires its caller to take card->controls_rwsem manually before the call for avoiding possible races. However, many callers don't care and miss the locking. Basically it's cumbersome and error-prone to enforce it to each caller. Moreover, card->controls_rwsem is a field that should be used only by internal or proper helpers, and it's not to be touched at random external places. This patch is an attempt to make those calls more consistent: now snd_ctl_remove() takes the card->controls_rwsem internally, just like other API functions for kctls. Since a few callers already take the controls_rwsem locks, the patch removes those locks at the same time, too. Link: https://lore.kernel.org/r/20230718141304.1032-5-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emu10k1: rework copyright statementsOswald Buddenhagen2023-07-179-22/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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-1712-112/+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: track loss of external clock on E-MU cardsOswald Buddenhagen2023-07-173-5/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 85;95;0c This uses IRQs to track spontaneous changes to the word clock source register. FWIW, that this can happen in the first place is the reason why it is futile to lock the clock source mixer setting while the device is open - we can't consistently control the rate anyway. Though arguably, we should reset any open streams when that happens, as they become corrupted anyway. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230715160738.326832-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emu10k1: remove superfluous IRQ enable state savingOswald Buddenhagen2023-07-136-69/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: fix return value of snd_emu1010_adc_pads_put()Oswald Buddenhagen2023-07-131-2/+5
| | | | | | | | | | | | | | | | | | It returned zero even if the value had changed. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230712145750.125086-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | ALSA: emu10k1: make E-MU dock monitoring interrupt-drivenOswald Buddenhagen2023-07-104-30/+38
|/ | | | | | | | ... instead of using a one-second polling timer. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230710065956.1246364-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: actually show some S/PDIF status in /proc for E-MU cardsOswald Buddenhagen2023-06-131-0/+8
| | | | | | | | | | | The file is called spdif-in, but we abused it to show only sample rates from various sources. Rectify it as far as possible (the FPGA doesn't give us a lot of information). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-10-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 timer for E-MU cards at 44.1 kHz word clockOswald Buddenhagen2023-06-131-2/+18
| | | | | | | | | The timer was presuming a fixed 48 kHz word clock, like the rest of the code. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-8-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: fix synthesizer pitch for E-MU cards at 44.1 kHzOswald Buddenhagen2023-06-132-1/+10
| | | | | | | | | | | | | | | | | | This is only a very partial fix - the frequency-dependent envelope & LFO register values aren't adjusted. But I'm not sure they were even correct at 48 kHz to start with, as most of them are precalculated by common code which assumes an EMU8K-specific 44.1 kHz word clock, and it seems somewhat unlikely that the hardware's register interpretation was adjusted to compensate for the different word clock. In any case I'm not going to spend time on fixing that, as this code is unlikely to be actually used by anyone today. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-6-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: query rate of external clock sources on E-MU cardsOswald Buddenhagen2023-06-132-21/+73
| | | | | | | | | | | | | | | | | | | | The value isn't used yet; the subsequent commits will do that. This ignores the existence of rates above 48 kHz, which is fine, as the hardware will just switch to the fallback clock source when fed with a rate which is incompatible with the base clock multiplier, which currently is always x1. The sample rate display in /proc spdif-in is adjusted to reflect our understanding of the input rates. This is tested only with an 0404b card without sync card, so there is a lot of room for improvement. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-4-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: make available E-MU clock sources card-specificOswald Buddenhagen2023-06-133-75/+105
| | | | | | | | | | | | The actually available clock sources depend on the available audio input ports and dedicated clock input ports. This includes refactoring the code to be data-driven to remain manageable. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230612191325.1315854-3-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-133-26/+70
| | | | | | | | | | | | | | | | 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: vastly improve usefulness of info in /procOswald Buddenhagen2023-06-052-144/+110
| | | | | | | | | | | | | | | | | | | | - Include the FX bus map, without which the already present send routing info would require looking up the documentation. - Include the physical I/O channels as known to the driver - Make the multi-channel capture map actually name the mapped input channels rather than "FXBUS" (Audigy) or even "???" (SbLive) - The latter two are omitted for E-MU cards, as their physical I/O is routed through the FPGA - While at it, make the "Card" field somewhat more useful This includes de-duplicating the label tables between emuproc and emufx, updating/improving the FX bus label table, and making the SB Live! 5.1 multi-track capture channel mapping hack data-driven. Tested-by: Jonathan Dowland <jon@dow.land> Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230526101659.437969-7-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: make E-MU FPGA register dump in /proc more usefulOswald Buddenhagen2023-06-052-4/+67
| | | | | | | | | | | Include the routing information, which can be actually read back. Somewhat as a drive-by, make the register dump format less obscure - the previous one made no sense at all. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230526101659.437969-6-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: include FX send amounts in /proc outputOswald Buddenhagen2023-06-051-24/+25
| | | | | | | | | | | It seems to make little sense to include the FX send routing, but not the amounts. This also simplifies the code somewhat, and lines up the output. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230526101659.437969-5-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: actually disassemble DSP instructions in /procOswald Buddenhagen2023-06-051-19/+130
| | | | | | | | | | fx8010_acode is supposed to be a human-readable representation; the binary is already in fx8010_code. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230529095504.559054-1-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: fix writing 1st pointer-offset register set through /procOswald Buddenhagen2023-06-051-4/+7
| | | | | | | | | | | | | The limits were appropriate only for the 2nd set. FWIW, the channel count 4 for the 2nd set is suspicious as well - at least P17V_PLAYBACK_FIFO_PTR actually has 8 channels, and comments on HCFG2 hint at that as well. But all bitmasks are documented only for 4 channels. Anyway, rectifying that is out of scope for this patch. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230526101659.437969-3-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: emu10k1: hide absent 2nd pointer-offset register set from /procOswald Buddenhagen2023-06-051-9/+13
| | | | | | | | | | | The 2nd register set belongs to the P16V chip (or embedded P17V module), so there is nothing to show when no such part is present. Gen2 E-MU cards have a P17V, but it's entirely unused, so we hide it there as well. Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Link: https://lore.kernel.org/r/20230526101659.437969-2-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-21 14:29:29 +0000