Change Details

Refactor pcm_chnalloc() and merge with parts of vchan_setnew() (now removed) and dsp_open()’s channel creation into a new dsp_chn_alloc() function. The function is responsible for either using a free HW channel (if vchans are disabled), or allocating a new vchan. Clean up allocated vchans associated with a given dsp_cdevpriv on dsp_close() instead of leaving them unused. hw.snd.maxautovchans and dev.pcm.X.{play|rec}.vchans now work as tunables to only enable/disable vchans, as opposed to setting their number and/or (de-)allocating vchans. Since these sysctls do not trigger any (de-)allocations anymore, their effect is instantaneous, whereas before we could have frozen the machine (when trying to allocate new vchans) when setting dev.pcm.X.{play|rec}.vchans to a very large value. Create a new "primary" channel sublist so that we do not waste time looping through all channels in dsp_chn_alloc(), since we are only looking for a parent channel to either use, or add a new vchan to. This guarantees a steady traversal speed, as the parent channels are most likely going to be just a handful (2). What was currently in place was a loop through the whole channel list, which meant that the traversal would take longer the more channels were added to that list. Previously the vchan_setmaxauto() call in pcm_register() would eventually trigger a call to chn_reset() on the primary (parent) channels with, usually, whatever \*vchanformat and \*vchanrate were set to. To compensate for this, set \*vchanformat and \*vchanrate already in pcm_init() and add a chn_reset() call in chn_init() and assign them as the channel speed, instead of using the defaults (AFMT_U8 format and 8000 rate). Sponsored by: The FreeBSD Foundation MFC after: 1 week

Refactor pcm_chnalloc() and merge with parts of vchan_setnew() (now removed) and dsp_open()’s channel creation into a new dsp_chn_alloc() function. The function is responsible for either using a free HW channel (if vchans are disabled), or allocating a new vchan. Clean up allocated vchans associated with a given dsp_cdevpriv on dsp_close() instead of leaving them unused. hw.snd.vchans_enable (previously hw.snd.maxautovchans) and dev.pcm.X.{play|rec}.vchans now work as tunables to only enable/disable vchans, as opposed to setting their number and/or (de-)allocating vchans. Since these sysctls do not trigger any (de-)allocations anymore, their effect is instantaneous, whereas before we could have frozen the machine (when trying to allocate new vchans) when setting dev.pcm.X.{play|rec}.vchans to a very large value. Create a new "primary" channel sublist so that we do not waste time looping through all channels in dsp_chn_alloc(), since we are only looking for a parent channel to either use, or add a new vchan to. This guarantees a steady traversal speed, as the parent channels are most likely going to be just a handful (2). What was currently in place was a loop through the whole channel list, which meant that the traversal would take longer the more channels were added to that list. Previously the vchan_setmaxauto() call in pcm_register() would eventually trigger a call to chn_reset() on the primary (parent) channels with, usually, whatever \*vchanformat and \*vchanrate were set to. To compensate for this, set \*vchanformat and \*vchanrate already in pcm_init() and add a chn_reset() call in chn_init() and assign them as the channel speed, instead of using the defaults (AFMT_U8 format and 8000 rate). Sponsored by: The FreeBSD Foundation MFC after: 1 week

Refactor pcm_chnalloc() and merge with parts of vchan_setnew() (now removed) and dsp_open()’s channel creation into a new dsp_chn_alloc() function. The function is responsible for either using a free HW channel (if vchans are disabled), or allocating a new vchan. Clean up allocated vchans associated with a given dsp_cdevpriv on dsp_close() instead of leaving them unused. hw.snd.maxautovchans and dev.pcm.X.{play|rec}.vchans now work as_enable (previously hw.snd.maxautovchans) and tunables to only enable/disable vchans,dev.pcm.X.{play|rec}.vchans now work as opposedtunables to setting theironly enable/disable number and/or (de-)allocating vchans., Since these sysctls do not triggeras opposed to setting their number and/or (de-)allocating any (de-)allocations anymore, their effect is instantaneous,vchans. whereasSince these sysctls do not trigger any (de-)allocations anymore, before we could have frozen the machine (when trying to allocate newtheir effect is instantaneous, whereas before we could have frozen the machine (when trying to allocate new vchans) when setting dev dev.pcm.X.{play|rec}.vchans to a very large value. Create a new "primary" channel sublist so that we do not waste time looping through all channels in dsp_chn_alloc(), since we are only looking for a parent channel to either use, or add a new vchan to. This guarantees a steady traversal speed, as the parent channels are most likely going to be just a handful (2). What was currently in place was a loop through the whole channel list, which meant that the traversal would take longer the more channels were added to that list. Previously the vchan_setmaxauto() call in pcm_register() would eventually trigger a call to chn_reset() on the primary (parent) channels with, usually, whatever \*vchanformat and \*vchanrate were set to. To compensate for this, set \*vchanformat and \*vchanrate already in pcm_init() and add a chn_reset() call in chn_init() and assign them as the channel speed, instead of using the defaults (AFMT_U8 format and 8000 rate). Sponsored by: The FreeBSD Foundation MFC after: 1 week