Developer Resources
Board support packages
Foundry27 projects
Forums
Home
Developer Resources
Technical Articles

QNX Technical Articles

QNX® Software Development Platform 7.0—Audio (Build 7.0.237.S201706290957): Release Notes

Date of this edition: July 11, 2017

This update includes fixes to existing functionality and generic audio drivers for the Audio components in the QNX Software Development Platform.

Target OS: This update is compatible with targets that are running the QNX® Neutrino® RTOS 7.0.

Host OS: To apply this update, you must have installed the QNX Software Development Platform 7.0 on one of the following development hosts:

  • Microsoft Windows 10 Professional 64-bit, Windows 8.1 Professional 64-bit, or Windows 7 Professional 64-bit
  • Linux Red Hat Enterprise Linux 7 64-bit, or Ubuntu Desktop 16.04 LTS 64-bit
  • macOS version 10.10, 10.11, 10.12

Contents

Throughout this document, you may see reference numbers associated with particular issues, changes, etc. When corresponding with our Technical Support staff about a given issue, please quote the relevant reference number. You might also find the reference numbers useful for tracking issues as they become fixed.

What's in this update?

Packaging changes

This update separates the Audio core functionality and drivers into the following packages:

  • Audio - Core
  • Audio - Drivers AVB
  • Audio - Drivers PC Generic
  • Audio - Drivers USB

Separate packages permit you to update the Audio core functionality without updating your existing drivers, but if you update a driver, the Audio core functionality must also be updated. You'll find the Audio - Core package under the Updates tab in the QNX Software Centre; the drivers are under the Available tab.

Caution: As part of the transition to the packaging changes, if you install only the Audio – Core package, the previous audio drivers from the QNX SDP 7.0, Build GA 201702151847 release are removed. If you require the AVB, PC Generic, or USB drivers, you must install the driver packages provided with this update separately. Future updates won’t uninstall the audio drivers when you install only the Audio – Core package.

Files and binaries installed with this update

You can use the QNX Software Center on your development host to see the contents of the packages.

To see the contents of the Audio - Core package, do the following:

  1. On the Updates tab, expand Target Packages and then Audio.
  2. Right-click QNX SDP 7.0 Audio - Core and then choose Properties.
  3. In the Properties for QNX SDP 7.0 Audio - Core window, click Package Contents.

To see the contents of a driver package, do the following:

  1. On the Available tab, expand Target Packages and then Audio.
  2. Right-click the appropriate QNX SDP 7.0 Audio - Drivers package and choose Properties.
  3. In the Properties window, click Package Contents.

Functionality updates

This update provides the following functionality and behavior changes:

  • Previously, audio management preemption didn't occur when you enabled audio ducking on a subchannel that wasn't in an active, streaming state (e.g., calling snd_pcm_channel_audio_ducking()). Active subchannels are in the RUNNING, SUSPENDED, or PAUSED state.

    This update fixes the issue to permit audio preemption to occur on a non-active channel and allow a subchannel to receive SND_PCM_EVENT_* events when you enable ducking behavior on a non-active subchannel. Now this allows, for example, a subchannel to transition from the PREPARED to the SUSPENDED state.

    Note: Audio preemption doesn't occur unless you call snd_pcm_*_prepare(). You can call snd_pcm_channel_audio_ducking() before or after the subchannel transitions to the PREPARED state.

    The following is a summary of the state transitions that can occur with this update when audio management policies are in place:

    • If a subchannel is in the READY state, audio ducking policies are applied, but audio management preemption policies are not, and therefore the subchannel stays in the READY state.
    • If the subchannel is in a PREPARED state and audio preemption occurs, the subchannel changes to the SUSPENDED state.
      • If the client application attempts to start the subchannel while it's in the SUSPENDED state, what occurs depends on whether it's soft- or hard-suspended:
        • If the subchannel is soft-suspended and the client application calls snd_pcm_*_go() or snd_pcm_*_write() (depending on your start mode), it transitions to the RUNNING state.
        • If the subchannel is hard-suspended, it remains in the SUSPENDED state, but if the audio type is configured to pause, it moves to the PAUSED state when the SUSPENDED state is cleared.
          Note: You can transition to the PAUSED state only if you have called snd_pcm_*_go() or snd_pcm_*_write() while the subchannel was SUSPENDED.
      • If the preemption state is cleared and the client application didn't previously called snd_pcm_*_go() or snd_pcm_*_write(), the subchannel transitions back to the PREPARED state.
      • If the subchannel isn't streaming and snd_pcm_*_resume() is called while the subchannel is soft-suspended, the subchannel transitions back to the PREPARED state.
  • Previously, when you grouped audio subchannels together using the snd_pcm_link() call, you could start the audio streams only by meeting the start mode condition. With this update, you can also call snd_pcm_*_resume(), snd_pcm_*_pause(), and snd_pcm_*_prepare() on the grouped PCM handles.

    This default behavior is referred to as synchronized behavior and is the default PCM link mode (SND_PCM_LINK_MODE_SYNC). You can change this behavior using the snd_pcm_link_mode() and snd_pcm_transition() functions. Both these functions are described in "API updates."

  • Previously, the audio management polices weren't correctly applied to subchannels that were grouped together. Subchannels in the same PCM link group caused audio management polices to be applied on one another. For example, if you had two subchannels grouped together and one of those streams was playing, but then you played the second stream in that group (which is the same audio type), incorrect audio ducking occurred where the first stream would have audio ducking applied to it so that the second stream could play.

    This update applies audio management policies so that grouped subchannels are treated as a single audio stream rather individual streams.

  • Previously, there was no way to determine whether you were soft- or hard-suspended. With this release, you can use the snd_pcm_channel_status_t to determine the status using the ducking_state member.
  • When your subchannel went through the software mixer ("sw_mixer") and you paused the audio stream (calling snd_pcm_*_pause()), it ramped down the volume, but immediately transitioned to the PAUSED state. The transition to PAUSED state shouldn't have occurred until the volume had ramped down to zero.

    With this update, the snd_pcm_*_pause() call blocks until the software mixer completes ramping down the volume to zero. Only after the volume ramps down to zero does the subchannel transition to the PAUSED state. It's important to note that if you don't use a software mixer, no ramping occurs.

API updates

The following section describes API changes introduced by this update:

  • snd_pcm_link_mode(snd_pcm_t *handle, int mode)

    Set the link mode for a subchannel in a group. Within the group, you can configure different subchannels to have different modes—in other words, you can mix the modes that are set on different PCM handles belonging to the same group. For example, if you have a group of four subchannels, you could set the mode of three of them to SND_PCM_LINK_MODE_SYNC and the remaining subchannel to SND_PCM_LINK_MODE_ASYNC.

    Arguments:

    handle
    A handle to the subchannel in the PCM group.
    mode
    The behavior of how calls to one thread impact the other subchannels in the same group. You can use one of the following modes:
    • SND_PCM_LINK_MODE_SYNC — (Default) The subchannels in the group synchronize together to respond to a call made to a subchannel in the group. For example, if you call snd_pcm_*_resume() on one subchannel in the group, the other subchannels in the group respond to the snd_pcm_*_resume() call and transition to the RUNNING state.
    • SND_PCM_LINK_MODE_ASYNC — For audio management purposes, the subchannels that are grouped together are treated as a single audio stream, but synchronization of the calls made to a subchannel in the group won't occur. For example, if you call snd_pcm_*_resume(), only the specified subchannel resumes playing.
    • SND_PCM_LINK_MODE_TRANSITION — Start playback on the PCM handles in the group that have this mode set when the current PCM handle's buffer is empty.

  • snd_pcm_link_transition (snd_pcm_t handle)

    Indicate to the specified PCM handle to trigger other handles in the group to start playback as soon as the specified audio subchannel's currently buffered data has been completely written to the hardware. This allows you to transition playback from one PCM handle to another with minimal gap between playback. For example, if you had two subchannels in a group and you set the mode to SND_PCM_LINK_MODE_TRANSITION for both, then when you call snd_pcm_link_transition() on the active PCM handle, as it nears completion, the other subchannel is triggered to start playing.

    Arguments:

    handle
    A PCM handle that may or may not belong to a group.

  • int snd_pcm_link( snd_pcm_t *pcm1, snd_pcm_t *pcm2 )

    Link two PCM streams (either playing or capturing) together such that they always stream at the same time. Starting one stream causes the other streams in the group to start. When audio management is applied to the PCM streams for playback, the subchannels in the PCM link group are treated as a single audio stream (or session). You can set the mode if you don't want the default synchronous behavior using snd_pcm_link_mode(). Regardless of the mode you choose, audio management policies are applied to the grouped PCM streams as single audio stream.

    PCM handles for playback must have the same audio type for this function to create a new link to a group; otherwise the call fails. In addition, pcm2 mustn't already belong to a PCM link group. PCM handles for capture aren't required to be the same audio type.

    Arguments:

    pcm1
    A PCM handle that may or may not belong to a group.
    pcm2
    This can only be a PCM handle. This must not belong to existing group.

Fixed issues

This update has these fixes, which are available in the Audio - Core package:

  • A subchannel with forced ducking applied now gets its volume updated. (Ref# J2160685)
  • A subchannel that's soft-suspended and has forced ducking applied now correctly transitions to the PREPARED state after snd_pcm_*_resume() is called. (Ref# J2174444 )
  • When a subchannel has audio ducking applied while in the PAUSED state, the volume level now correctly ramps down when audio management policies are in effect. (Ref# J2148307)
  • The delta between volume settings found in the PCM Mixer Control (mix_ctrl) and voice settings are now correct. (Ref# J2146547 )
  • When ASRC is enabled, heap corruption no longer occurs when snd_pcm_plugin_write() is called with a large buffer (e.g., 22 KB) and when snd_pcm_plugin_update_src() isn't called. (Ref# J949121)
  • It's now possible to indicate soft- or hard-suspended states. (Ref# J1677662)
  • PCM events are now properly generated for non-preempting audio types. (Ref# J1680676)
  • When playing an 8-bit wave file, a pop noise no longer occurs. (Ref# J1683951)
  • The snd_pcm_channel_status_t.free value correctly shows the maximum value when the client application stops writing. (Ref# J1688947)
  • Mixer settings are now restored when io-audio is restarted. (Ref# J1690075)

Driver fixes:

  • Mute controls for the AC'97 audio codecs (such as VMWare) now function. (Ref# J1690678—Available as part of the Audio - Drivers PC Generic package)
  • Audio on the ASRock Beebox is no longer corrupted. (Ref# J2185387—Available as part of the Audio - Drivers PC Generic package)
  • It's now possible to set the maximum volume to 100% when using certain types of USB audio dongles, such as C-Media dongles. (Ref #J2178836—Available as part of the Audio - Drivers USB package)

Known issues

These are the known issues with this update:

  • When you call pcm_link() after you call pcm_link_mode(), it resets the mode of the specified handles to SND_PCM_LINK_MODE_SYNC.

    For example, suppose you had linked stream #1 and stream #2, and then called snd_pcm_link_mode() on both streams to set the mode to SND_PCM_LINK_MODE_ASYNC. If you then add stream #3 to the link group by linking stream #1 and stream #3, snd_pcm_link() would reinitialize the link modes for stream #1 and #3 to SND_PCM_LINK_MODE_SYNC and stream #2 would remain set to SND_PCM_LINK_MODE_ASYNC. (Ref# J2198452)

    Workaround: Call pcm_link_mode() after you have finished adding the audio streams to your PCM link group.

Technical support

To obtain technical support for any QNX product, visit the Support area on our website (www.qnx.com). You'll find a wide range of support options, including community forums.