Seems like osspd messes up gbsplay.

For example, try to play the gbs included with gbsplay:
~$ dpkg -L gbsplay | grep "\.gbs"
/usr/share/doc/gbsplay/examples/nightmode.gbs.gz

Slowing down the samplerate (-r option of gbsplay) seems
to be making things better but still way afar for being
correct.

Sophoklis

Hi,

thanks for the report. This is probably an upstream problem, but before
I forward the report, I need some more information. In particular, which
osspd backend are you using? Please send the output of

  update-alternatives --display ossp-slave

Kind regards
Ralf

$ update-alternatives --display ossp-slave
ossp-slave - auto mode
  link currently points to /usr/lib/osspd/ossp-padsp
/usr/lib/osspd/ossp-alsap - priority 60
/usr/lib/osspd/ossp-padsp - priority 70
Current 'best' version is '/usr/lib/osspd/ossp-padsp'.

If set to point to ossp-alsap everything seem to be working smoothly
for a while but it will eventually get messed up too.

Sophokils

Hi,

I can confirm the issue, that doesn't sound right.

I will forward your report to upstream, maybe someone there has an idea.
However, osspd upstream is not very active, so I wouldn't hold up my
hopes too high.

Kind regards
Ralf

Hi all,

a Debian user reports that combining gbsplay and osspd results in
totally messed-up playback:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753395

You can reproduce the problem on a Debian system by installing "gbsplay"
and then running somewhere

cp /usr/share/doc/gbsplay/examples/nightmode.gbs.gz .
gunzip nightmode.gbs.gz
gbsplay nightmode.gbs

The result doesn't sound quite right to me (though I have no way to tell
what correct playback would sound like).
This is with osspd 1.3.2.

Is this list currently considered the osspd bugtracker, or should I also
created a ticket in the SF project?

Kind regards
Ralf
(Debian osspd maintainer)