execution should help us avoiding potential deadlock and illegal locking
while sleeping in various mixer -> usb calls. To enable it, use
hint.uaudio.%d.async="1" or sysctl dev.uaudio.%d.async=1. Default is
disable, to remain compatible with old behaviour (with slight risk of
potential deadlock).
- SWAPLR quirk for (unknown, luckily it is mine) broken uaudio stick.
Fixing by rewiring is impossible without damaging it. Luckily,
we can fix it using "other" methods :) .
- Add uaudio_get_vendor(), _product() and _release() in uaudio.c
(currently used by uaudio_pcm quirk).
- Implement CHANNEL_SETFRAGMENTS().
- Drop channel locking in few places where it is about to sleep
somewhere. This should help eliminating illegal locking acquisition
where the current thread is about to sleep, and also few deadlock
cases. Dropping it right here is quite safe since it is already
protected by CHN_F_BUSY flag and other threads won't bother to touch it.
Solving other illegal locking issues are quite tricky without converting
most usbd_do_request() calls to its equivalent _async() calls,
which I intend to do it later after getting full test report from
other people with different uaudio hardwares.
- Fix memory leak issues during detach. This seems common to any drivers
(notably emu10kx, csapcm?) with bridge functions.
revision 1.98 is NOT merged, because FreeBSD does not support this
syntax.
revision 1.99 is NOT merged, "const poisoning" part is not applicable
to FreeBSD. There is no variable shadowing, GCC can't find
this one (but there are others)
revision 1.100 is NOT merged, because it was null patch (no changes)
revision 1.101 is NOT merged, there is no BIT() macro in FreeBSD
revision 1.102 is merged
revision 1.103 is partially merged. There is no ai.ifaceh in FreeBSD
revision 1.104 is NOT merged
revision 1.105 is merged
revision 1.106 is not merged, because of rev. 1.107
revision 1.107 is a backuout of 1.106
Submitted by: Yuriy Tsibizov <Yuriy.Tsibizov@gfk.ru>
in every sense.
General
-------
- Multichannel safe, endian safe, format safe
* Large part of critical pcm filters such as vchan.c, feeder_rate.c,
feeder_volume.c, feeder_fmt.c and feeder.c has been rewritten so that
using them does not cause the pcm data to be converted to 16bit little
endian.
* Macrosses for accessing pcm data safely are defined within sound.h in
the form of PCM_READ_* / PCM_WRITE_*
* Currently, most of them are probably limited for mono/stereo handling,
but the future addition of true multichannel will be much easier.
- Low latency operation
* Well, this require lot more works to do not just within sound driver,
but we're heading towards right direction. Buffer/block sizing within
channel.c is rewritten to calculate precise allocation for various
combination of sample/data/rate size. As a result, applying correct
SNDCTL_DSP_POLICY value will achive expected latency behaviour simmilar
to what commercial 4front driver do.
* Signal handling fix. ctrl+c of "cat /dev/zero > /dev/dsp" does not
result long delay.
* Eliminate sound truncation if the sound data is too small.
DIY:
1) Download / extract
http://people.freebsd.org/~ariff/lowlatency/shortfiles.tar.gz
2) Do a comparison between "cat state*.au > /dev/dsp" and
"for x in state*.au ; do cat $x > /dev/dsp ; done"
- there should be no "perceivable" differences.
Double close for PR kern/31445.
CAVEAT: Low latency come with (unbearable) price especially for poorly
written applications. Applications that trying to act smarter
by requesting (wrong) blocksize/blockcount will suffer the most.
Fixup samples/patches can be found at:
http://people.freebsd.org/~ariff/ports/
- Switch minimum/maximum sampling rate limit to "1" and "2016000" (48k * 42)
due to closer compatibility with 4front driver.
Discussed with: marcus@ (long time ago?)
- All driver specific sysctls in the form of "hw.snd.pcm%d.*" have been
moved to their own dev sysctl nodes, notably:
hw.snd.pcm%d.vchans -> dev.pcm.%d.vchans
Bump __FreeBSD_version.
Driver specific
---------------
- Ditto for sysctls.
- snd_atiixp, snd_es137x, snd_via8233, snd_hda
* Numerous cleanups and fixes.
* _EXPERIMENTAL_ polling mode support using simple callout_* mechanisme.
This was intended for pure debugging and latency measurement, but proven
good enough in few unexpected and rare cases (such as problematic shared
IRQ with GIANT devices - USB). Polling can be enabled/disabled through
dev.pcm.0.polling. Disabled by default.
- snd_ich
* Fix possible overflow during speed calibration. Delay final
initialization (pcm_setstatus) after calibration finished.
PR: kern/100169
Tested by: Kevin Overman <oberman@es.net>
* Inverted EAPD for few Nec VersaPro.
PR: kern/104715
Submitted by: KAWATA Masahiko <kawata@mta.biglobe.ne.jp>
Thanks to various people, notably Joel Dahl, Yuriy Tsibizov, Kevin Oberman,
those at #freebsd-azalia @ freenode and others for testing.
Joel Dahl will do the manpage update.
commit.
1) sys/dev/sound/pcm/sound.h
sys/dev/sound/pcm/channel.c
* Be more specific: SD_F_SOFTVOL -> SD_F_SOFTPCMVOL
2) sys/dev/sound/pcm/mixer.[ch]
* Implement
mix_setparentchild()
mix_setrealdev()
mix_getparent()
mix_getchild()
The purpose of these functions is implement relative volume
adjustment, such as to tie two or more mixer device into a
single logical device. Usefull for the upcoming HDA driver
and few AC97 codec (such as AD1981B) where the master volume
"vol" need to be implemented using this logical manner.
3) sys/dev/sound/pcm/ac97_patch.[ch]
* Patch for AD1981B codec to enable (automuting) headphone jack sense.
4) sys/dev/sound/pcm/ac97.c
* Implement proper logical master volume for AD9181B codec
through various mix_set{parentchild,realdev}(). Tie both
"ogain" (headphone volume) and "phone" (speaker/lineout) to
a logical "vol".
5) sys/dev/sound/pcm/usb/uaudio_pcm.c
* ditto, for "vol" -> { "pcm" }.
MFC after: 1 month
dereferencing) since a NULL value would be a bug here.
Note: Both affected functions look very similar. A refactoring may
be beneficial.
CID: 483, 485
Found with: Coverity Prevent(tm)
Discussed with: ariff
MFC after: 5 days
It may be the case that you may hear some unwanted noise while
playing back with 24/32 bit. This is a problem in the USB system.
Explanation from Hans Petter Selasky:
---snip---
The current USB sound driver only uses one isochronous
buffer, that is restarted when it is completed. This will lead to a short
period of time, +1ms, where no sound data is sent to the external USB device.
Depending on the load of your computer, this can be as much as 50ms. So the
USB sound driver must use 2 isochronous transfers. At the beginning one will
queue both. Then these are restarted on completion. This will result in a
constant-rate data stream to the external sound device, a minimum sound
buffer equal to the size of the isochronous buffer, and possibly the sound
will reach your ears with less delay. Little delay is a result of constant
data rate. Currently only my USB driver will support that. If one tries that
with the USB driver in *BSD, then it will crash at the first moment one gets
a buffer underrun.
---snip---
Submitted by: Kazuhito HONDA <kazuhito@ph.noda.tus.ac.jp>
Mono-recording still not tested by: julian
this buffer anyway so the constraint that it had to be DMA capable only
caused pain when devices failed to aquire the memory. Use a regular
malloc instead with sndbuf_setup.
Approved by: tanimura (mentor)
One of a set of patches submitted by Kazuhito HONDA
to make the usb audio driver a lot more capable.
PR: 75274
Submitted by: Kazuhito HONDA (kazuhito at ph dot noda dot tus dot ac dot jp)
Obtained from: NetBSD (indirectly)
MFC after: 2 weeks
- `sound'
The generic sound driver, always required.
- `snd_*'
Device-dependent drivers, named after the sound module names.
Configure accordingly to your hardware.
In addition, rename the `snd_pcm' module to `sound' in order to sync
with the driver names.
Suggested by: cg
Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg.
Lockfunc allows a driver to provide a function for managing its locking
semantics while using busdma. At the moment, this is used for the
asynchronous busdma_swi and callback mechanism. Two lockfunc implementations
are provided: busdma_lock_mutex() performs standard mutex operations on the
mutex that is specified from lockfuncarg. dftl_lock() is a panic
implementation and is defaulted to when NULL, NULL are passed to
bus_dma_tag_create(). The only time that NULL, NULL should ever be used is
when the driver ensures that bus_dmamap_load() will not be deferred.
Drivers that do not provide their own locking can pass
busdma_lock_mutex,&Giant args in order to preserve the former behaviour.
sparc64 and powerpc do not provide real busdma_swi functions, so this is
largely a noop on those platforms. The busdma_swi on is64 is not properly
locked yet, so warnings will be emitted on this platform when busdma
callback deferrals happen.
If anyone gets panics or warnings from dflt_lock() being called, please
let me know right away.
Reviewed by: tmm, gibbs
debugging levels to off by default. Now that debug levels can be
tweaked by sysctl we don't need to go through hoops to get the
different usb parts to produce debug data.
This driver actually works slightly better on -stable than on -current
(the system locks on detach on -current), so it should be MFC'd somewhat
sooner.
This driver currently points out a difficulty in the sound device framework.
The PCM unregister routine is allowed to refuse the detach if the device is
in use. In the case of a USB device, however, this unregistration is much more
mandatory in nature, since the device is *actually* gone when this call is
made. The sound subsystem really should not refuse an unregistration and
should take its own steps to reject further I/O. As a result, if you detach
a USB sound device while it is in use, you can expect a panic shortly
thereafter.
This device cannot currently record audio. Some routines are unwritten as
of yet in uaudio.c to support recording.
This device hangs my -current box on detach. I don't know why. This does
not happen on my -stable machine.
Obtained from: Hiroyuki Aizu
MFC after: 2 weeks
