Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2020-11-21T06:58:42Zhttps://gitlab.xiph.org/xiph/opus/-/issues/2336cmake - Rename options in CMake to have 1-1 mapping to autotools2020-11-21T06:58:42ZMarcus Asteborgcmake - Rename options in CMake to have 1-1 mapping to autotoolsdisable in autotools should be disable in cmake etc.disable in autotools should be disable in cmake etc.https://gitlab.xiph.org/xiph/opus/-/issues/2335Remove WINCE define from source2020-11-21T06:59:12ZMarcus AsteborgRemove WINCE define from sourceWINCE is no longer relevant platform and defines can be removed from Opus sourceWINCE is no longer relevant platform and defines can be removed from Opus sourcehttps://gitlab.xiph.org/xiph/opus/-/issues/2332cmake - Add OPUS_TARGET_ARCH for crosscompiling from commandline for CMake build2020-11-21T06:59:41ZMarcus Asteborgcmake - Add OPUS_TARGET_ARCH for crosscompiling from commandline for CMake buildCurrently one need to use toolchain file for cross compiling, for easier crosscompiling in CI we can add a option to CMake so all cross compile options can be specified through commandline without the need for toolchain files.Currently one need to use toolchain file for cross compiling, for easier crosscompiling in CI we can add a option to CMake so all cross compile options can be specified through commandline without the need for toolchain files.https://gitlab.xiph.org/xiph/ogg/-/issues/2300Check for overflow on growing buffer2020-08-09T22:44:22ZClément BœschCheck for overflow on growing bufferHi,
I came across this code while debugging an issue in libshout (https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2318), and it looked pretty unsafe to me: [0001-framing-check-for-overflow-on-growing-buffer.patch](/uploads/376286...Hi,
I came across this code while debugging an issue in libshout (https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2318), and it looked pretty unsafe to me: [0001-framing-check-for-overflow-on-growing-buffer.patch](/uploads/376286b5321247d4934f85e924bdb2be/0001-framing-check-for-overflow-on-growing-buffer.patch).
One could check that the `oy->storage<0` and similar checks are enough, but I still believe it's safer not to assign the invalid value in the first place.https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2318Misc memory fixes2020-10-21T08:50:28ZClément BœschMisc memory fixesHi,
2 memory fix patches (patch 1 is the most important one):
- [0001-Fix-cleanup-format-residual-after-close.patch](/uploads/445ae23a375206242940a51ee2f69e4b/0001-Fix-cleanup-format-residual-after-close.patch)
- [0002-Fix-check-ogg_sy...Hi,
2 memory fix patches (patch 1 is the most important one):
- [0001-Fix-cleanup-format-residual-after-close.patch](/uploads/445ae23a375206242940a51ee2f69e4b/0001-Fix-cleanup-format-residual-after-close.patch)
- [0002-Fix-check-ogg_sync_buffer-pointer-before-writing-to-.patch](/uploads/8e33e8f69d5bef238e5b7bcb51df3c92/0002-Fix-check-ogg_sync_buffer-pointer-before-writing-to-.patch)https://gitlab.xiph.org/xiph/icecast-website/-/issues/2054Google+ no longer exists2022-04-10T20:56:07ZTerence EdenGoogle+ no longer existsThe link to https://plus.google.com/100957455777699991449/about is no longer useful since G+ shut down.
It should be removed from https://gitlab.xiph.org/search?utf8=%E2%9C%93&snippets=false&scope=&repository_ref=master&search=100957455...The link to https://plus.google.com/100957455777699991449/about is no longer useful since G+ shut down.
It should be removed from https://gitlab.xiph.org/search?utf8=%E2%9C%93&snippets=false&scope=&repository_ref=master&search=100957455777699991449&group_id=2&project_id=7https://gitlab.xiph.org/xiph/opus/-/issues/2329Any plans to make new release?2023-04-20T23:34:55ZTomasz KłoczkoAny plans to make new release?Looks like it is alread +600 commits since last release +year ago.
I think that it would be good to flush currently committed changes and make new release :)Looks like it is alread +600 commits since last release +year ago.
I think that it would be good to flush currently committed changes and make new release :)https://gitlab.xiph.org/xiph/opus/-/issues/2328cmake - intrinsics is not enabled for x86 for non windows due to missing defines2022-07-12T14:05:59ZMarcus Asteborgcmake - intrinsics is not enabled for x86 for non windows due to missing defineshttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2317nanosleep patch2020-10-21T08:51:08ZRosen Penevnanosleep patchI can't create a merge request so here's a patch:
```
From 4467530c2396c61e886bf2dc4563be0e9c54394b Mon Sep 17 00:00:00 2001
From: Rosen Penev <rosenp@gmail.com>
Date: Fri, 3 Apr 2020 19:32:39 -0700
Subject: [PATCH] nonblocking: remove ...I can't create a merge request so here's a patch:
```
From 4467530c2396c61e886bf2dc4563be0e9c54394b Mon Sep 17 00:00:00 2001
From: Rosen Penev <rosenp@gmail.com>
Date: Fri, 3 Apr 2020 19:32:39 -0700
Subject: [PATCH] nonblocking: remove usleep usage
usleep is deprecated under POSIX 2008 and is optionally unavailable
with uClibc-ng.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
examples/nonblocking.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/examples/nonblocking.c b/examples/nonblocking.c
index 8e38a94..2f15b80 100644
--- a/examples/nonblocking.c
+++ b/examples/nonblocking.c
@@ -70,8 +70,10 @@ int main()
if (ret == SHOUTERR_BUSY)
printf("Connection pending...\n");
+ const struct timespec req = {0, 10 * 1000 * 1000};
+ struct timespec rem;
while (ret == SHOUTERR_BUSY) {
- usleep(10000);
+ nanosleep(&req, &rem);
ret = shout_get_connected(shout);
}
--
2.26.2
```Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2390status-json with fallback-mount2020-08-31T15:48:47ZIgor dWstatus-json with fallback-mountI have icecast 2.4.4 with win2016 server. I'm using a fallback-mount. When the fallback mount is active my player gets the metadata from this mount and works perfect. When the 'main' mount gets active, icecast switches perfect, and in my...I have icecast 2.4.4 with win2016 server. I'm using a fallback-mount. When the fallback mount is active my player gets the metadata from this mount and works perfect. When the 'main' mount gets active, icecast switches perfect, and in my status-json my 'main' mount is first presented so my player pickes te metadata correct. When the 'main' mount is lost and icecast switches to the fallback mount things go wrong. The music switches but in status-json the metadata from the 'main' mount is not dropped/removed so my player is looking to empty strings and is not presenting artist and song information. The 'main' mount is also not dropped in the icecast server status (but empty, containing no data). When i at this point also disconnect the fallback, both are removed from status-json. Is this a setting i have to change or a bug?
[Icecast_xml_settings.txt](/uploads/be6d02c1146dea8396b28c984b0178fa/Icecast_xml_settings.txt)https://gitlab.xiph.org/xiph/opus-tools/-/issues/2314Release new version (and builds) with the libopusenc gapless bug fixed2020-07-05T02:18:05ZAmanRelease new version (and builds) with the libopusenc gapless bug fixedlibopusenc 0.2.1 includes xiph/libopusenc@a852e9fbfd7c360e9078d124e73ec6eef2665148, which fixed a bug with encoding tracks gaplessly. It will be great if you can cut a new release with this included.libopusenc 0.2.1 includes xiph/libopusenc@a852e9fbfd7c360e9078d124e73ec6eef2665148, which fixed a bug with encoding tracks gaplessly. It will be great if you can cut a new release with this included.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2388Indefinite 100% CPU when disconnecting from SSL port when Icecast is running ...2021-01-23T08:17:31ZredactedscribeIndefinite 100% CPU when disconnecting from SSL port when Icecast is running inside a Podman container*UPDATE: This bug seems hard to track down and the solution as described below of spawning the Podman container as root rather than rootlessly doesn't actually work. It definitely seemed to be the fix last night, but I've now encountered...*UPDATE: This bug seems hard to track down and the solution as described below of spawning the Podman container as root rather than rootlessly doesn't actually work. It definitely seemed to be the fix last night, but I've now encountered the same high CPU usage problem that spawning as rootless was producing, but as root. Noteworthy is that I tested the same build process on the host system without containers, and the bug was no more, but judging how the bug has seemed to have has disappeared completely and then returned a few times, I'm not certain of the results. Leaving this report up as it could still lead to an answer.*
The easiest way for me to communicate the issue is through these steps:
- [Create a Let's Encrypt cert](https://certbot.eff.org/).
- Create `icecast.pem` using what Let's Encrypt produced: `fullchain.pem` + `privkey.pem`.
- Place `icecast.pem` into same dir as `Containerfile` and `entrypoint.sh` (attached files).
- [Install Podman](https://podman.io/getting-started/installation).
- As an unprivileged user, run: `podman build --force-rm -f Containerfile -t icecast`. This builds Icecast 2.4.4 from source with `--with-curl` and `--with-openssl` flags (`OpenSSL/1.1.1g` is what Alpine currently serves).
- Open ports `8000/tcp` and `8001/tcp` on the host if needed.
- Spawn an Icecast container (replace `<hostname>`):
```sh
podman run --rm --interactive --tty --publish 8000:8000 --publish 8001:8001 \
--env IC_HOSTNAME="<hostname>" \
--env IC_HTTP_PORT="8001" \
--env IC_HTTPS_PORT="8000" \
--env IC_LOG_LEVEL="4" \
--name icecast \
icecast
```
- To monitor Icecast's logs via the host, you can use `podman exec icecast tail /usr/local/var/log/icecast/access.log -f` and `podman exec icecast tail /usr/local/var/log/icecast/error.log -f`.
- Stream to the server's HTTPS port `8000` using a source client (in my case, Butt on Windows) with the default credentials.
- After connection, disconnect. `htop` on the host should now report 100% CPU for the container process, and reconnection via the source client should no longer be possible.
- Pressing `s` in `htop` on one of the two `icecast -c /usr/local/etc/icecast.xml` commands listed running at ~100% CPU, `strace` shows intense polling spam:
```sh
...
poll([{fd=7, events=POLLIN}], 1, 250) = 1 ([{fd=7, revents=POLLIN}])
read(7, read(7, read(7, read(7, ) = 1 ([{fd=7, revents=POLLIN}])
poll([{fd=7, events=POLLIN}], 1, 250) = 1 ([{fd=7, revents=POLLIN}])
read(7, "", 5) = 0
read(7, read(7, read(7, poll([{fd=7, events=POLLIN}], 1, 250) = 1 ([{fd=7, revents=POLLIN}])
...
```
For the other high CPU Icecast command, `strace` shows less spam:
```sh
...
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 300) = 0 (Timeout)
poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 300) = 0 (Timeout)
...
```
- With the container still running, running `podman exec icecast netstat -t` on the host shows Alpine waiting:
```sh
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 <hostname>:46372 <hostname>:8000 FIN_WAIT2
tcp 0 0 <hostname>:8000 <hostname>:46372 CLOSE_WAIT
netstat: /proc/net/tcp6: No such file or directory
```
It looks like the connection is never closed properly, as visiting `https://<hostname>:8000/admin/` and pressing `Kill Source` brings things back to normal. This is specifically confined to SSL as connecting to the HTTP port `8001` and then disconnecting has no adverse effects. Only the HTTPS port is affected.
~~The solution for me has been to spawn the Podman container as root rather than rootlessly. When doing so, Icecast doesn't get stuck in a loop waiting for the connection to drop after disconnection from HTTPS port (or whatever the exact issue is). Ideally, Icecast could function in a container run rootlessly as this is a major advantage of Podman's approach to containers over Docker's.~~
I am unsure if there is a bug on Podman's side (concerning container networking, or possible misconfiguration on my part), but I don't believe Icecast should be able to get stuck in this scenario producing 100% CPU indefinitely. Therefore, I have reported this here rather than to Podman.
Thanks.
Infos:
```
Icecast 2.4.4 (from source) running on Alpine inside the container
Podman 1.9.3
Fedora release 32 (Thirty Two)
Linux 5.6.19-300.fc32.x86_64
```
[icecast-indefinite-100_-cpu-bug-report.tar](/uploads/4840719fa9fe143617af35b9c78f6895/icecast-indefinite-100_-cpu-bug-report.tar)https://gitlab.xiph.org/xiph/opus/-/issues/2327CMake - Consistent warning levels between autotools and cmake2020-08-08T17:36:52ZMarcus AsteborgCMake - Consistent warning levels between autotools and cmakeIf things blow up on automake it should blow up on cmakeIf things blow up on automake it should blow up on cmakehttps://gitlab.xiph.org/xiph/libao/-/issues/2319When I try to fork Xiph.org/libao I get a "You have reached your project limits"2024-02-02T10:40:25ZGonzalo GarramunoWhen I try to fork Xiph.org/libao I get a "You have reached your project limits"When I try to fork Xiph.org/libao I get a "You have reached your project limits"
I would like to create a fork and set up a merge request please.When I try to fork Xiph.org/libao I get a "You have reached your project limits"
I would like to create a fork and set up a merge request please.https://gitlab.xiph.org/xiph/opus/-/issues/2324SILK complexity levels 1 and 2 are inconsistent2020-06-01T19:22:07ZFrancis QuiersSILK complexity levels 1 and 2 are inconsistentIn `silk_setup_complexity()`, it seems that the parameters chosen for complexity levels 2 and 3 are mostly swapped (except `nStatesDelayedDecision`)In `silk_setup_complexity()`, it seems that the parameters chosen for complexity levels 2 and 3 are mostly swapped (except `nStatesDelayedDecision`)https://gitlab.xiph.org/xiph/Infrastructure/-/issues/2231Update xiph.org/vorbis for gitlab2021-02-19T23:48:43ZRalph GilesUpdate xiph.org/vorbis for gitlabThe repo links still point to obsolete git.xiph.org, which has been down since the server crash.The repo links still point to obsolete git.xiph.org, which has been down since the server crash.https://gitlab.xiph.org/xiph/opus/-/issues/2323Equivalent bitrate calculation is broken for <20ms frame sizes2020-05-26T04:56:56ZHector MartinEquivalent bitrate calculation is broken for <20ms frame sizesThis leads to negative bitrates at smaller frame sizes, which does bad things like making all bands available for intensity stereo coding.
So, for example, encoding with these parameters:
`opusenc --hard-cbr --bitrate 192 --framesize 2...This leads to negative bitrates at smaller frame sizes, which does bad things like making all bands available for intensity stereo coding.
So, for example, encoding with these parameters:
`opusenc --hard-cbr --bitrate 192 --framesize 2.5`
Yields output that, when mono downmixed, sounds completely terrible, which definitely shouldn't happen at those bitrates (phase inversion intensity stereo should not be used).
Fix: [0001-celt_encoder-fix-equivalent-bitrate-calculation-for-.patch](/uploads/0cc8ff9d0576f97bfad81e649c8e67ec/0001-celt_encoder-fix-equivalent-bitrate-calculation-for-.patch)https://gitlab.xiph.org/xiph/speexdsp/-/issues/3Ubuntu Aaarch64 18.04 ./configure error2020-08-11T02:16:11ZStuartIanNaylorUbuntu Aaarch64 18.04 ./configure error
checking for cos in -lm... yes
./configure: line 13500: syntax error near unexpected token `FFT,'
./configure: line 13500: ` PKG_CHECK_MODULES(FFT, fftw3f)'
Tried installing all the fftw packages -dev also
Going to switch for debian ...
checking for cos in -lm... yes
./configure: line 13500: syntax error near unexpected token `FFT,'
./configure: line 13500: ` PKG_CHECK_MODULES(FFT, fftw3f)'
Tried installing all the fftw packages -dev also
Going to switch for debian and give it a go as you can tell apart from simple compiling I am lost.
Posted here also seems both Ubuntu & Debian tried 18.04 & 20.04 64 bit
https://github.com/xiph/speexdsp/issues/31#issuecomment-633379070https://gitlab.xiph.org/xiph/speexdsp/-/issues/2'AM_PROG_LIBTOOL' not found in library2020-05-24T21:19:03ZStuartIanNaylor'AM_PROG_LIBTOOL' not found in library```
ubuntu@ubuntu:~/speexdsp$ ./autogen.sh
Updating build configuration files, please wait....
configure.ac:26: warning: macro 'AM_PROG_LIBTOOL' not found in library
configure.ac:25: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
...```
ubuntu@ubuntu:~/speexdsp$ ./autogen.sh
Updating build configuration files, please wait....
configure.ac:26: warning: macro 'AM_PROG_LIBTOOL' not found in library
configure.ac:25: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:26: error: possibly undefined macro: AM_PROG_LIBTOOL
autoreconf: /usr/bin/autoconf failed with exit status: 1
```
Ubuntu 18.04 Aarch64 git clone https://gitlab.xiph.org/xiph/speexdsp.git -b SpeexDSP-1.2.0https://gitlab.xiph.org/xiph/icecast-server/-/issues/2386Unable to disable SSL build in libshout-2.4.32020-10-01T18:33:57ZNight GryphonUnable to disable SSL build in libshout-2.4.3./configure --without-openssl
still do ssl tests and add
#define HAVE_OPENSSL 1
to config.h which cause tls.c and other unwanted ssl stuff to build in to library./configure --without-openssl
still do ssl tests and add
#define HAVE_OPENSSL 1
to config.h which cause tls.c and other unwanted ssl stuff to build in to library