From 1d6a378c73e21a421024e226f336fceb966cad88 Mon Sep 17 00:00:00 2001 From: Mike Brady <4265913+mikebrady@users.noreply.github.com> Date: Wed, 28 Sep 2022 12:44:10 +0100 Subject: [PATCH 01/13] Small documentation change. --- AIRPLAY2.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/AIRPLAY2.md b/AIRPLAY2.md index 9029b462..122f1d91 100644 --- a/AIRPLAY2.md +++ b/AIRPLAY2.md @@ -9,7 +9,7 @@ Shairport Sync offers AirPlay 2 support for audio sources on iOS devices, Macs f * Realtime streams generally have a latency of about two seconds. Buffered Audio streams typically have a latency of half a second or less. * In AirPlay 2 mode, Shairport Sync reverts to "classic" AirPlay when iTunes on macOS or macOS Music plays to multiple speakers and one of more of them is compatible with AirPlay only. -- Devices running Shairport Sync in AirPlay 2 mode can be [added](https://github.com/mikebrady/shairport-sync/blob/development/ADDINGTOHOME.md) to the Home app. +- Devices running Shairport Sync in AirPlay 2 mode can be [added](ADDINGTOHOME.md) to the Home app. ## What Does Not Work - No AirPlay 2 for Windows iTunes. @@ -31,7 +31,7 @@ Here are some guidelines: * An up-to-date Linux or FreeBSD. This is important, as some of the libraries must be the latest available. * Shairport Sync will not run on a Mac because NQPTP, on which it relies, needs ports 319 and 320, which are already used by macOS. * A version of the [FFmpeg](https://www.ffmpeg.org) library with an AAC decoder capable of decoding Floating Planar -- `fltp` -- material. There is a guide [here](TROUBLESHOOTING.md#aac-decoder-issues-airplay-2-only) to help you find out if your system has it. -* An audio output, for example an ALSA device (or `sndio` in FreeBSD). The device must be capable of running at 44,100 frames per second. You can use an `sps-alsa-explore`](https://github.com/mikebrady/sps-alsa-explore) to test the suitability of hardware ALSA audio devices on your device. +* An audio output, for example an ALSA device (or `sndio` in FreeBSD). The device must be capable of running at 44,100 frames per second. You can use an [`sps-alsa-explore`](https://github.com/mikebrady/sps-alsa-explore) to test the suitability of hardware ALSA audio devices on your device. Other backends continue to work as with "classic" Shairport Sync. ## Guides From e56e047f79cd89be6af2dd3951fda1e409d11c58 Mon Sep 17 00:00:00 2001 From: Mike Brady <4265913+mikebrady@users.noreply.github.com> Date: Thu, 29 Sep 2022 12:27:12 +0100 Subject: [PATCH 02/13] Fix a layout error and reference. --- AIRPLAY2.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/AIRPLAY2.md b/AIRPLAY2.md index 122f1d91..9029b462 100644 --- a/AIRPLAY2.md +++ b/AIRPLAY2.md @@ -9,7 +9,7 @@ Shairport Sync offers AirPlay 2 support for audio sources on iOS devices, Macs f * Realtime streams generally have a latency of about two seconds. Buffered Audio streams typically have a latency of half a second or less. * In AirPlay 2 mode, Shairport Sync reverts to "classic" AirPlay when iTunes on macOS or macOS Music plays to multiple speakers and one of more of them is compatible with AirPlay only. -- Devices running Shairport Sync in AirPlay 2 mode can be [added](ADDINGTOHOME.md) to the Home app. +- Devices running Shairport Sync in AirPlay 2 mode can be [added](https://github.com/mikebrady/shairport-sync/blob/development/ADDINGTOHOME.md) to the Home app. ## What Does Not Work - No AirPlay 2 for Windows iTunes. @@ -31,7 +31,7 @@ Here are some guidelines: * An up-to-date Linux or FreeBSD. This is important, as some of the libraries must be the latest available. * Shairport Sync will not run on a Mac because NQPTP, on which it relies, needs ports 319 and 320, which are already used by macOS. * A version of the [FFmpeg](https://www.ffmpeg.org) library with an AAC decoder capable of decoding Floating Planar -- `fltp` -- material. There is a guide [here](TROUBLESHOOTING.md#aac-decoder-issues-airplay-2-only) to help you find out if your system has it. -* An audio output, for example an ALSA device (or `sndio` in FreeBSD). The device must be capable of running at 44,100 frames per second. You can use an [`sps-alsa-explore`](https://github.com/mikebrady/sps-alsa-explore) to test the suitability of hardware ALSA audio devices on your device. +* An audio output, for example an ALSA device (or `sndio` in FreeBSD). The device must be capable of running at 44,100 frames per second. You can use an `sps-alsa-explore`](https://github.com/mikebrady/sps-alsa-explore) to test the suitability of hardware ALSA audio devices on your device. Other backends continue to work as with "classic" Shairport Sync. ## Guides From 94701c5d3b0e71d79ae8510d2ea2fa96b309dcba Mon Sep 17 00:00:00 2001 From: Mike Brady <4265913+mikebrady@users.noreply.github.com> Date: Thu, 29 Sep 2022 12:39:37 +0100 Subject: [PATCH 03/13] Fix Bug Report template. --- .github/ISSUE_TEMPLATE/Bug Report.yaml | 31 +++++++++++++++++++++----- 1 file changed, 25 insertions(+), 6 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/Bug Report.yaml b/.github/ISSUE_TEMPLATE/Bug Report.yaml index 11e2f3a1..8017b5db 100644 --- a/.github/ISSUE_TEMPLATE/Bug Report.yaml +++ b/.github/ISSUE_TEMPLATE/Bug Report.yaml @@ -1,12 +1,12 @@ -name: Bug Report -description: File a bug report -title: "[Bug]: " -labels: ["bug"] +name: Issue Report +description: File an Issue +title: "[Problem]: " +labels: ["new issue"] body: - type: markdown attributes: value: | - Thanks for taking the time to fill out this bug report! + Thanks for taking the time to fill out this report! - type: textarea id: what-happened attributes: @@ -20,6 +20,13 @@ body: label: Relevant log output description: Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks. render: shell + - type: textarea + id: os + attributes: + label: Operating System? + description: What Operating System are you running on ? (`uname -a`) + validations: + required: true - type: textarea id: version attributes: @@ -27,6 +34,17 @@ body: description: What version of Shairport Sync are you running? (`shairport-sync -V`) validations: required: true + - type: dropdown + id: install + attributes: + label: How did you install Shairport Sync? + options: + - Homebrew for Mac + - Docker + - A package manager (apt, yum, pkg, etc.) + - Built from source + validations: + required: true - type: checkboxes id: checked-current-issues attributes: @@ -34,4 +52,5 @@ body: description: Please check previous issues (including closed ones) for duplicates. options: - label: Confirm - required: true \ No newline at end of file + required: true + From 44c5f18b0e640138328ca4574ebafb7f4416242e Mon Sep 17 00:00:00 2001 From: Mike Brady <4265913+mikebrady@users.noreply.github.com> Date: Thu, 29 Sep 2022 12:46:05 +0100 Subject: [PATCH 04/13] Add docker-build-on-formal-release.yaml and stale.yaml to the branch. --- .../docker-build-on-formal-release.yaml | 83 +++++++++++++++++++ .github/workflows/stale.yaml | 21 +++++ 2 files changed, 104 insertions(+) create mode 100644 .github/workflows/docker-build-on-formal-release.yaml create mode 100644 .github/workflows/stale.yaml diff --git a/.github/workflows/docker-build-on-formal-release.yaml b/.github/workflows/docker-build-on-formal-release.yaml new file mode 100644 index 00000000..fc698373 --- /dev/null +++ b/.github/workflows/docker-build-on-formal-release.yaml @@ -0,0 +1,83 @@ +# Builds & pushes a docker image when a "formal" release tag of the format X, X.Y or X.Y.Z occurs, where X, Y and Z are all numbers. +# It seems this yaml has to exist on the branch the tag refers to. + +# Thanks to Charles Omer for the workfow upon which this is based. + +# The following docker tags are created & pushed: +# trial, trial-classic +# not building 'latest' yet... + +name: Formal (X, X.Y or X.Y.Z) release tags -- docker build and push. + +on: + push: + tags: + - '[0-9]+\.[0-9]+\.[0-9]+' # e.g. 8.9.0 + - '[0-9]+\.[0-9]+' # e.g. 8.9 + - '[0-9]+' # e.g. 8 + - '[0-9]+\.[0-9]+rc[0-9]+' # e.g. 4.1rc0 + +env: + DOCKER_PLATFORMS: linux/386,linux/amd64,linux/arm/v6,linux/arm64,linux/arm/v7 + +jobs: + main: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v2 + with: + fetch-depth: 0 + + - name: Set SHAIRPORT_SYNC_BRANCH env. + run: | + raw=$(git branch -r --contains ${{ github.ref }}) + branch=${raw##*/} + echo "SHAIRPORT_SYNC_BRANCH=${branch}" >> $GITHUB_ENV + + - name: Set tag env + run: echo "GIT_TAG=${GITHUB_REF#refs/*/}" >> $GITHUB_ENV + + - name: Determine NQPTP env (part 1). + if: ${{ env.SHAIRPORT_SYNC_BRANCH == 'development' }} + run: echo "NQPTP_BRANCH=development" >> $GITHUB_ENV + + - name: Determine NQPTP env (part 2). + if: ${{ env.SHAIRPORT_SYNC_BRANCH != 'development' }} + run: echo "NQPTP_BRANCH=main" >> $GITHUB_ENV + + - name: Set up QEMU + uses: docker/setup-qemu-action@v1 + + - name: Set up Docker Buildx + uses: docker/setup-buildx-action@v1 + + - name: Login to Docker Registry + uses: docker/login-action@v1 + with: + registry: ${{ secrets.DOCKER_REGISTRY }} + username: ${{ secrets.DOCKER_REGISTRY_USER }} + password: ${{ secrets.DOCKER_REGISTRY_TOKEN }} + + - name: Build and push + uses: docker/build-push-action@v2 + with: + context: ./ + file: ./docker/Dockerfile + platforms: ${{ env.DOCKER_PLATFORMS }} + push: true + tags: trial + build-args: | + SHAIRPORT_SYNC_BRANCH=${{ env.SHAIRPORT_SYNC_BRANCH }} + NQPTP_BRANCH=${{ env.NQPTP_BRANCH }} + + - name: Build and push (Classic) + uses: docker/build-push-action@v2 + with: + context: ./ + file: ./docker/classic/Dockerfile + platforms: ${{ env.DOCKER_PLATFORMS }} + push: true + tags: trial-classic + build-args: | + SHAIRPORT_SYNC_BRANCH=${{ env.SHAIRPORT_SYNC_BRANCH }} diff --git a/.github/workflows/stale.yaml b/.github/workflows/stale.yaml new file mode 100644 index 00000000..51658c01 --- /dev/null +++ b/.github/workflows/stale.yaml @@ -0,0 +1,21 @@ +name: 'Close stale issues and PRs' +on: + schedule: + - cron: '0 0 * * *' + +permissions: + issues: write + pull-requests: write + +jobs: + stale: + runs-on: ubuntu-latest + steps: + - uses: actions/stale@v4 + with: + stale-issue-message: 'This issue has been inactive for 45 days so will be closed 7 days from now. To prevent this, please remove the "stale" label or post a comment.' + stale-pr-message: 'This PR has been inactive for 45 days so will be closed 7 days from now. To prevent this, please remove the "stale" label or post a comment.' + operations-per-run: 100 + # These are the defaults at the time of writing. https://github.com/marketplace/actions/close-stale-issues + # days-before-stale: 45 + # days-before-close: 7 From 07426e17c8b720cb58de19ba3056c9e5c71f2031 Mon Sep 17 00:00:00 2001 From: Mike Brady <4265913+mikebrady@users.noreply.github.com> Date: Thu, 29 Sep 2022 12:48:37 +0100 Subject: [PATCH 05/13] Take update to CAR INSTALL. --- CAR INSTALL.md | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/CAR INSTALL.md b/CAR INSTALL.md index 8cc47b04..c2259a5f 100644 --- a/CAR INSTALL.md +++ b/CAR INSTALL.md @@ -215,3 +215,43 @@ Install the Raspberry Pi in your car. It should be powered from a source that is When the power source is switched on, typically when you start the car, it will take maybe a minute for the system to boot up. ### Enjoy! + +--- + +## Updating +From time to time, you may wish to update this installation. However, in order to update Shairport Sync, you must reconnect the system to a network that can access the internet. The easiest thing is to temporarily reconnect to the network you used when you created the system. To do that, you have to temporarily undo the "Final Steps" and some of the "Raspberry Pi Specific" steps you used. This will enable you to connect your device back to the network it was created on. You should then be able to update the operating system and libraries in the normal way and then update Shairport Sync. + +So, take the following steps: + +1. If it's a Raspberry Pi and you have enabled the Read-only mode, you must take the device out of Read-only mode: +Run `sudo raspi-config` and then choose `Performance Options` > `Overlay Filesystem` and choose to disable the overlay filesystem and to set the boot partition not to be write-protected. This is so that changes can be written to the file system; you can make the filesystem read-only again later. Save the changes and reboot the system. + +2. If you have disabled the `dhcpcd`, `wpa_supplicant` or `systemd-timesyncd` services as suggested in the "Optimise startup time -- Raspberry Pi Specific" section, you need to temporarily re-enable them: +`# systemctl enable dhcpcd.service` +`# systemctl enable wpa_supplicant.service` +`# systemctl enable systemd-timesyncd.service` +Reboot. + +3. To allow your device to reconnect to the network it was created on, edit `/etc/dhcpcd.conf` and comment out the following line at the start: +`denyinterfaces wlan0` +so that it looks like this: +`# denyinterfaces wlan0` +From this point on, if you reboot the machine, it will connect to the network it was configured on, i.e. the network you used when you set it up for the first time. This is because the name and password of the network it was created on would have been placed in `/etc/wpa_supplicant/wpa_supplicant` when the system was initially configured and will still be there. + +4. Reboot and do Normal Updating + + You can perform updates in the normal way -- see [UPDATING](https://github.com/mikebrady/shairport-sync/blob/master/UPDATING.md). When you are finished, you need to undo the temporary changes you made to the setup, as follows: + +5. If you had temporarily re-enabled services that are normally disabled, then it's time to disable them again: +`# systemctl disable dhcpcd.service` +`# systemctl disable wpa_supplicant.service` +`# systemctl disable systemd-timesyncd.service` + +6. To re-enable the system to create its own network, edit `/etc/dhcpcd.conf` and uncomment the line that you had temporarily commented out at the start of the update. Change: +`# denyinterfaces wlan0` +so that it looks like this: +`denyinterfaces wlan0` + +7. Reboot. The system should start as it would if it was in the car. + +8. If the device is a Raspberry Pi and you wish to make the file system read-only, connect to the system, run `sudo raspi-config` and then choose `Performance Options` > `Overlay Filesystem`. In there, choose to enable the overlay filesystem, and to set the boot partition to be write-protected. Do a final reboot and check that everyting is in order. From 01b4fbddd11aae206788c96ca543a435a2c5cfff Mon Sep 17 00:00:00 2001 From: Mike Brady <4265913+mikebrady@users.noreply.github.com> Date: Thu, 29 Sep 2022 12:53:32 +0100 Subject: [PATCH 06/13] Take more uptodate version of documents --- RELEASENOTES.md | 27 ++++++++++++++++++++++++++- TROUBLESHOOTING.md | 9 +++++++++ 2 files changed, 35 insertions(+), 1 deletion(-) diff --git a/RELEASENOTES.md b/RELEASENOTES.md index bfb2c8fa..9fdc0628 100644 --- a/RELEASENOTES.md +++ b/RELEASENOTES.md @@ -1,4 +1,29 @@ -Please see the [Release Notes for 3.3](https://github.com/mikebrady/shairport-sync/releases/tag/3.3). +Version 4.1-rc0 Release Candidate +==== + +Really Big Update -- AirPlay 2! +---- +Version 4.1 brings support for AirPlay 2 operation. It works with iOS, iPadOS, macOS, HomePod mini and Apple TV sources, but not with Windows. +Limited support is available for HomeKit -- Shairport Sync speakers can be added to the Home app, though not all features are working. +AirPlay 2 operation requires a companion program called NQPTP and requires a somewhat more powerful system. Please see [AIRPLAY2.md](./AIRPLAY.md) for more. + +Note that you can still build Shairport Sync to support "classic" AirPlay (aka "AirPlay 1") as before. + +The various guides for building and updating Shairport Sync have been consolidated into [BUILD.md](./BUILD.md). + +Here is a brief list of the high-level new features and changes (more to be added): +* AirPlay 2 operation. +* Improved `libao` backend for better compatibility with HomeBrew installations. +* Improved MQTT and D-Bus facilities. +* Automatically-generated Docker images (forthcoming). + +There have been many many bug fixes and enhancements to the core operation of Shairport Sync. + +Version 3.3.9 +==== +**Bug Fix** +* Version 3.3.9 fixes a build failure with convolution raised since `automake 1.16.5` and https://git.savannah.gnu.org/cgit/automake.git/commit/?id=f4a3a70f69e1dbccb6578f39ef47835098a04624. +Further details in [Fabrice Fontaine's original PR](https://github.com/mikebrady/shairport-sync/pull/1314) to the `development` branch. Many thanks to [Fabrice Fontaine](https://github.com/ffontaine) for the bug report and for the fix. Version 3.3.8 ==== diff --git a/TROUBLESHOOTING.md b/TROUBLESHOOTING.md index 73e9e7b9..d6436fdf 100644 --- a/TROUBLESHOOTING.md +++ b/TROUBLESHOOTING.md @@ -15,6 +15,15 @@ If you are using the default ALSA backend, don't forget to check two simple thin You can use `alsamixer` for both of theses checks. A muted output has the letter(s) `M` as its value. Select it and type `M` again to unmute. +### Audio is Delayed! +If the audio from your Shairport Sync device is delayed slightly by comparison with audio from other devices, it may be that the output device being fed by Shairport Sync is introducing a delay while it processes the audio. If your output device include any digital processing component, it probably delays the audio while it processing occurs. + +For instance, if your output device is a HDMI-connected device such as a TV or an AV Receiver, it will almost certainly delay audio by anything up to several hundred milliseconds. + +The fix for this is to ask Shairport Sync to provide the audio to the output device _slightly ahead of time_, so that by the time the output device has processed it, the audio emerges at exactly the right time. The setting to look for is in the `general` section of the Shairport Sync configuration file and is called `audio_backend_latency_offset_in_seconds`. By default it is `0.0` seconds. + +For example, if your output device is delaying audio by 100 milliseconds (0.1 seconds), set the `audio_backend_latency_offset_in_seconds` to `-0.1`, so that audio is provided to your output device 0.1 seconds early. Remember to uncomment the line by removing the initial `//` and then restart Shairport Sync (or reboot the device) for the changed setting to take effect. + ### WiFi adapter running in power-saving / low-power mode **Check Throughput** From 2bc62c7dd90abba1f164f615f4bad2772487a951 Mon Sep 17 00:00:00 2001 From: Mike Brady <4265913+mikebrady@users.noreply.github.com> Date: Fri, 30 Sep 2022 10:18:51 +0100 Subject: [PATCH 07/13] Close the DAC when the keep_dac_busy flag is changed (by the activity monitor) from true to false. Wait a little longer for the DAC to drop all frames. --- audio_alsa.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/audio_alsa.c b/audio_alsa.c index fc53ee65..62db843f 100644 --- a/audio_alsa.c +++ b/audio_alsa.c @@ -1850,7 +1850,8 @@ static int do_close() { // debug(1,"alsa: do_close() -- closing the output device"); if ((derr = snd_pcm_drop(alsa_handle))) debug(1, "Error %d (\"%s\") dropping output device.", derr, snd_strerror(derr)); - usleep(5000); // this make the function pthread cancellable + usleep(10000); // wait for the hardware to do its trick. BTW, this make the function pthread + // cancellable if ((derr = snd_pcm_hw_free(alsa_handle))) debug(1, "Error %d (\"%s\") freeing the output device hardware.", derr, snd_strerror(derr)); debug(2, "alsa: do_close() -- closing alsa handle"); @@ -2061,9 +2062,12 @@ static void *alsa_buffer_monitor_thread_code(__attribute__((unused)) void *arg) int error_count = 0; int error_detected = 0; int okb = -1; - while (error_detected == - 0) { // if too many play errors occur early on, we will turn off the disable stanby mode + // if too many play errors occur early on, we will turn off the disable standby mode + while (error_detected == 0) { + int keep_dac_busy_has_just_gone_off = 0; if (okb != config.keep_dac_busy) { + if ((okb != 0) && (config.keep_dac_busy == 0)) + keep_dac_busy_has_just_gone_off = 1; debug(2, "keep_dac_busy is now \"%s\"", config.keep_dac_busy == 0 ? "no" : "yes"); okb = config.keep_dac_busy; } @@ -2081,7 +2085,7 @@ static void *alsa_buffer_monitor_thread_code(__attribute__((unused)) void *arg) if (do_open(1) == 0) // no automatic setup of rate and speed if necessary debug(2, "alsa: alsa_buffer_monitor_thread_code() -- output device opened; " "alsa_backend_state => abm_connected"); - } else if ((alsa_backend_state == abm_connected) && (config.keep_dac_busy == 0)) { + } else if ((alsa_backend_state != abm_disconnected) && (keep_dac_busy_has_just_gone_off != 0)) { stall_monitor_start_time = 0; // frame_index = 0; // measurement_data_is_valid = 0; From 97fa75e87c60a53c588b559a4cc146dc6713e820 Mon Sep 17 00:00:00 2001 From: Mike Brady <4265913+mikebrady@users.noreply.github.com> Date: Fri, 30 Sep 2022 10:37:48 +0100 Subject: [PATCH 08/13] Update RELEASENOTES-DEVELOPMENT.md --- RELEASENOTES-DEVELOPMENT.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/RELEASENOTES-DEVELOPMENT.md b/RELEASENOTES-DEVELOPMENT.md index c90367b9..e2a63f6e 100644 --- a/RELEASENOTES-DEVELOPMENT.md +++ b/RELEASENOTES-DEVELOPMENT.md @@ -1,3 +1,13 @@ +Version 4.1-dev-599-g2bc62c7d +==== + +**Enhancements** +* Added some GitHub Actions to test different combinations of builds -- hopefully the result will be fewer bugs. Thanks to [Charles Omer](https://github.com/charlesomer) for the inspiration to try these in the first place. + +**Bug Fixes** +* Fixed a bug where the DAC was not closed after the active timeout when the `alsa` `disable_standby_mode` was set to `"auto"`. Thanks to [Tim Curtis](https://github.com/moodeaudio) for an exemplary [bug report](https://github.com/mikebrady/shairport-sync/issues/1546). +* Fixed a couple of bugs (found with GitHub Actions) in the installers on both `systemd` and System V systems. + Version 4.1-dev-551-g30aaabc4 ==== **Update** @@ -8,7 +18,7 @@ Version 4.1-dev-551-g30aaabc4 Version 4.1-dev-548-g7dc077e2 ==== -* Removed the workaround for the apparent bug in AirPlay 2 Buffered Streams in iOS 16.0. A number of approaches were tried. The most aurally successful is left in the code but is disabled. Basically, it delays the timing of the frames following the 2,122 frame discontinuity by 2,112 frames. This eliminates the timing discontinuity but delays the AirPlay stream by 47.9 ms, and this can be heard in some situations. So it looks as if the bug -- if that's what it is -- can't easily be worked around. It has not been fixed by iOS 16.0.2, unfortunately. +* Removed the workaround for the apparent bug in AirPlay 2 Buffered Streams in iOS 16.0. A number of approaches were tried. The most aurally successful is left in the code but is disabled. Basically, it delays the timing of the frames following the 2,112 frame discontinuity by 2,112 frames. This eliminates the timing discontinuity but delays the AirPlay stream by 47.9 ms, and this can be heard in some situations. So it looks as if the bug -- if that's what it is -- can't easily be worked around. It has not been fixed by iOS 16.0.2, unfortunately. Version 4.1-dev-543-g24f06b81 ==== From 98744211a710af654c7a2e056a71901342027546 Mon Sep 17 00:00:00 2001 From: Mike Brady <4265913+mikebrady@users.noreply.github.com> Date: Sat, 1 Oct 2022 15:32:53 +0100 Subject: [PATCH 09/13] Disable the timer on the RTSP link. OwnTone doesn't supply regular traffic here. --- rtsp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/rtsp.c b/rtsp.c index d61ffeb1..aa48d976 100644 --- a/rtsp.c +++ b/rtsp.c @@ -1275,7 +1275,9 @@ void clear_ptp_clock() { ssize_t read_from_rtsp_connection(rtsp_conn_info *conn, void *buf, size_t count) { // first try to read with a timeout, to see if there is any traffic... - ssize_t response = timed_read_from_rtsp_connection(conn, 10000000000L, buf, count); + // ssize_t response = timed_read_from_rtsp_connection(conn, 20000000000L, buf, count); + // actually don't use a timeout -- OwnTone doesn't supply regular traffic. + ssize_t response = timed_read_from_rtsp_connection(conn, 0, buf, count); if ((response == -1) && ((errno == EAGAIN) || (errno == EWOULDBLOCK))) { if (conn->rtsp_link_is_idle == 0) { debug(1, "Connection %d: RTSP connection is idle.", conn->connection_number); From f70d9a0f0cecf1b5f3d65b139ec33b3b68d5a2ca Mon Sep 17 00:00:00 2001 From: Mike Brady <4265913+mikebrady@users.noreply.github.com> Date: Sat, 1 Oct 2022 15:38:15 +0100 Subject: [PATCH 10/13] Update RELEASENOTES-DEVELOPMENT.md --- RELEASENOTES-DEVELOPMENT.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/RELEASENOTES-DEVELOPMENT.md b/RELEASENOTES-DEVELOPMENT.md index e2a63f6e..3bd8aaa0 100644 --- a/RELEASENOTES-DEVELOPMENT.md +++ b/RELEASENOTES-DEVELOPMENT.md @@ -1,3 +1,8 @@ +Version 4.1-dev-601-g98744211 +==== +**Bug Fix** +* Recent versions of Shairport Sync have a "heartbeat" checker, to try to determine when the client has stopped running without warning -- typically when it has gone to sleep. Unfortunately, it interferes with some non-Apple clients, so it has been disabled in this update. + Version 4.1-dev-599-g2bc62c7d ==== From b653027f7457ca57b723d29f26a1f8bf3730c82f Mon Sep 17 00:00:00 2001 From: Mike Brady <4265913+mikebrady@users.noreply.github.com> Date: Mon, 3 Oct 2022 17:56:02 +0100 Subject: [PATCH 11/13] Only call the volume hook once for each volume event even when the dbus interface is included. --- ADVANCED TOPICS/Events.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/ADVANCED TOPICS/Events.md b/ADVANCED TOPICS/Events.md index 0fd15ead..26a777de 100644 --- a/ADVANCED TOPICS/Events.md +++ b/ADVANCED TOPICS/Events.md @@ -1,8 +1,14 @@ ## Events -Shairport Sync can run programs just before it starts to play an audio stream and just after it finishes. -You specify them using the `sessioncontrol` group settings `run_this_before_play_begins` and `run_this_after_play_ends`. -This is to facilitate situations where something has to be done before and after playing, e.g. switching on an amplifier beforehand -and switching it off afterwards. +Shairport Sync can run programs when certain "events" occur. The events are: +1. When Shairport Sync become `active` or `inactive`. Shairport Sync is normally in the `inactive` state when no audio is being played. When audio is sent to Shairport Sync, it will transition from `inactive` to `active`. When the audio stops, Shairport Sync will start a timer. If audio restarts before the timer reaches the value of the `active_state_timeout` configuration setting (10 seconds by default), Shairport Sync will stay `active`. However, if no more audio is received before the timer reaches the `active_state_timeout` value, Shairport Sync will transition to `inactive`. The overall effect of this is that Shairport Sync will go `active` when a track is played and will stay active in the interval between tracks, so long as the interval is less than the `active_state_timeout`. + 1. Set the `run_this_before_entering_active_state` setting to the full path name to the program to run before Shairport Sync goes `active`. + 2. Set the `run_this_after_exiting_active_state` setting to the full path name to the program to run after Shairport Sync goes `inactive`. + 3. Set the `active_state_timeout` setting to the maximum amount of time to wait for play to resume before going `inactive`. +3. When audio starts and stops playing. + 1. Set the `run_this_before_play_begins` setting to the full path name to the program to run just before Shairport Sync starts playing. + 2. Set the `run_this_after_play_ends` setting to the full path name to the program to run after Shairport Sync stops playing. +5. When the volume is adjusted. Shairport Sync can run a program whenever the volume is set or changed. You specify the full path name to the program to run using the `general` group setting `run_this_when_volume_changes`. + Set the `wait_for_completion` value to `"yes"` for Shairport Sync to wait until the respective commands have been completed before continuing. Note that the full path to the programs must be specified, and script files will not be executed unless they are marked as executable From f96fa2f793b8ec5d4465a9a736a30661af6d03d6 Mon Sep 17 00:00:00 2001 From: Mike Brady <4265913+mikebrady@users.noreply.github.com> Date: Mon, 3 Oct 2022 17:56:18 +0100 Subject: [PATCH 12/13] Only call the volume hook once for each volume event even when the dbus interface is included. --- rtsp.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/rtsp.c b/rtsp.c index aa48d976..adc9db23 100644 --- a/rtsp.c +++ b/rtsp.c @@ -3523,14 +3523,16 @@ void handle_set_parameter_parameter(rtsp_conn_info *conn, rtsp_message *req, debug(2, "Connection %d: request to set AirPlay Volume to: %f.", conn->connection_number, volume); // if we are playing, go ahead and change the volume - lock_player(); - config.airplay_volume = volume; - if (playing_conn == conn) - player_volume(volume, conn); - unlock_player(); #ifdef CONFIG_DBUS_INTERFACE if (dbus_service_is_running()) { - shairport_sync_set_volume(shairportSyncSkeleton, config.airplay_volume); + shairport_sync_set_volume(shairportSyncSkeleton, volume); + } else { +#endif + lock_player(); + if (playing_conn == conn) + player_volume(volume, conn); + unlock_player(); +#ifdef CONFIG_DBUS_INTERFACE } #endif } else if (strncmp(cp, "progress: ", strlen("progress: ")) == From 821e700f7cd1b2dc964e873d20a178dd26e4e0fd Mon Sep 17 00:00:00 2001 From: Mike Brady <4265913+mikebrady@users.noreply.github.com> Date: Mon, 3 Oct 2022 18:02:01 +0100 Subject: [PATCH 13/13] Update RELEASENOTES-DEVELOPMENT.md --- RELEASENOTES-DEVELOPMENT.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/RELEASENOTES-DEVELOPMENT.md b/RELEASENOTES-DEVELOPMENT.md index 3bd8aaa0..cff8c0ab 100644 --- a/RELEASENOTES-DEVELOPMENT.md +++ b/RELEASENOTES-DEVELOPMENT.md @@ -1,3 +1,8 @@ +Version 4.1-dev-604-gf96fa2f7 +==== +**Bug Fix** +* If the D-Bus interface was enabled, each change in volume control was calling the volume event hook twice. Fixed. + Version 4.1-dev-601-g98744211 ==== **Bug Fix**