osspd-users — Users of OSS Proxy

Re: [OSS Proxy] OSS wrappers, version 097dc7b, not working under Arch Linux 4.2.3, PulseAudio 7.0

[Ralf J. <po...@ra...>]

Hi,

> I'm running an up to date Arch Linux system (kernel 4.2.3) with
> Alsa/PulseAudio 7.0 (which is working fine).  I want to use an old
> (commercial) application, that still uses OSS, so I would like to use
> the ossd-wrapper, version 097dc7b.  Unfortunately, they do not seem to
> work.  A more precise description of the errors can be found here:
> https://bbs.archlinux.org/viewtopic.php?id=203964
> As of writing, there were no replies to my initial question/problem.
> 
> I cloned the git repo and built them, running the tests gave me some
> errors:
>     % make test
>     gcc -Wall   -o osstest osstest.c 
>     test_open@122 test succeeded (mixerfd >= 0)
>     test_open@131 test failed (ro_fd >= 0): Input/output error
>     test_open@139 test failed (wo_fd >= 0): Input/output error
>     test_open@147 test failed (rw_fd >= 0): Input/output error
>     test_mixer@162 test succeeded (ret >= 0)
>     Mixer id: OSS Proxy
>     Name: Mixer
>     Tests: 3 errors 2 success
>     Makefile:65: recipe for target 'test' failed
>     make: *** [test] Error 3
> 
> Does anyone have an idea what might be going wrong?  I would appreciate
> any help.  I would also happily provide you with more information --
> just ask...

Disclaimer: I have little idea about the inner workings of osspd. I just
have it working fine here on my machine with PA 7.0. The test suite
never worked for me, either.
I am testing it like this:

> gst-launch-1.0 filesrc location=./filename.ogg ! oggdemux ! vorbisdec ! audioconvert ! audioresample ! osssink

So, in principle, osspd *is* compatible with PA 7.0. My first guess for
your problem would be that something is wrong with the permissions
somewhere. Do you have udev set up to set the permissions of /dev/dsp
etc. correctly?

> $ ls -lah /dev/dsp /dev/adsp 
> crw-rw-rw- 1 root root 14, 12 Okt 26 19:04 /dev/adsp
> crw-rw-rw- 1 root root 14,  3 Okt 26 19:04 /dev/dsp

Is there anything special, non-default about your PA setup? Like, I
don't know, using a system daemon or any other changes you made in
/etc/pulse or ~/.pulse ?

Kind regards,
Ralf

[OSS Proxy] OSS wrappers, version 097dc7b, not working under Arch Linux 4.2.3, PulseAudio 7.0

[Michael K. <kop...@ya...>]

Hi,

I'm running an up to date Arch Linux system (kernel 4.2.3) with
Alsa/PulseAudio 7.0 (which is working fine).  I want to use an old
(commercial) application, that still uses OSS, so I would like to use
the ossd-wrapper, version 097dc7b.  Unfortunately, they do not seem to
work.  A more precise description of the errors can be found here:
https://bbs.archlinux.org/viewtopic.php?id=203964
As of writing, there were no replies to my initial question/problem.

I cloned the git repo and built them, running the tests gave me some
errors:
    % make test
    gcc -Wall   -o osstest osstest.c 
    test_open@122 test succeeded (mixerfd >= 0)
    test_open@131 test failed (ro_fd >= 0): Input/output error
    test_open@139 test failed (wo_fd >= 0): Input/output error
    test_open@147 test failed (rw_fd >= 0): Input/output error
    test_mixer@162 test succeeded (ret >= 0)
    Mixer id: OSS Proxy
    Name: Mixer
    Tests: 3 errors 2 success
    Makefile:65: recipe for target 'test' failed
    make: *** [test] Error 3

Does anyone have an idea what might be going wrong?  I would appreciate
any help.  I would also happily provide you with more information --
just ask...

Sincerely,
Michael

-- 
Michael Kopp <kop...@ya...>

[OSS Proxy] Sound playing too fast

[Ralf J. <po...@ra...>]

Hi everybody,

I recently got a bug-report for osspd at Debian, that I'm pretty sure is
not caused by Debian packaging, so I'm forwarding it.

You can find all the details at
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791864>. The short
summary: For some games (notably xscavenger, xgalaga), the sounds are
played too fast and hence in a too low pitch. This sounds like the
sample-rate is not negotiated correctly.

Does anybody have an idea of that's easily fixable?

Kind regards,
Ralf

Re: [OSS Proxy] EIO from osspd

[Paul F. <pg...@fo...>]

ralf wrote:
 > Hi,
 > 
 > > it still seems like i can't get sound via oss and directly via pulseaudio
 > > (from the local browser) at the same time -- nasd blocks until the active
 > > browser window goes away.  is this normal?  i would have thought a system
 > > purported to be as sophisticated as pulseaudio would allow mixing of the
 > > streams.
 > 
 > That's certainly not normal. PulseAudio mixes osspd-Streams and "native"
 > PA streams just fine here. (Well, technically speaking, PulseAudio
 > doesn't even see a difference.)
 > 
 > Maybe you somehow managed to end up with multiple PulseAudio daemons
 > running (like, if you or your distro did something weird with PA like
 > running a single, system-wide daemon, and now there's also a per-user
 > daemon)? Sorry, I don't have much of an idea what could be going on.

i do always run pulseaudio as a system daemon, since i need to play
remote streams when no one is logged in, and because otherwise nasd
doesn't come up properly.  but i presume that should make no difference
(as long as only one daemon is running).

in any case, thanks for the confirmation as to how it should work. 
that gives me more confidence towards looking for my misconfig.  :-)

paul
=----------------------
 paul fox, pg...@fo... (arlington, ma, where it's 62.8 degrees)

Re: [OSS Proxy] EIO from osspd

[Ralf J. <po...@ra...>]

Hi,

> it still seems like i can't get sound via oss and directly via pulseaudio
> (from the local browser) at the same time -- nasd blocks until the active
> browser window goes away.  is this normal?  i would have thought a system
> purported to be as sophisticated as pulseaudio would allow mixing of the
> streams.

That's certainly not normal. PulseAudio mixes osspd-Streams and "native"
PA streams just fine here. (Well, technically speaking, PulseAudio
doesn't even see a difference.)

Maybe you somehow managed to end up with multiple PulseAudio daemons
running (like, if you or your distro did something weird with PA like
running a single, system-wide daemon, and now there's also a per-user
daemon)? Sorry, I don't have much of an idea what could be going on.

Kind regards,
Ralf

Re: [OSS Proxy] EIO from osspd

[<pg...@fo...>]

my apologies.  it seems that somewhere during my testing, pulseaudio
had died or been killed.

the errors from nasd were a result of pulseaudio having gone missing.

the osstest errors, however, seem to be the result of insufficient
permissions:  sudo eliminates the EIO errors.

sorry for the noise.

it still seems like i can't get sound via oss and directly via pulseaudio
(from the local browser) at the same time -- nasd blocks until the active
browser window goes away.  is this normal?  i would have thought a system
purported to be as sophisticated as pulseaudio would allow mixing of the
streams.

paul

i wrote:
 > hi --
 > 
 > i'm trying to run nasd on osspd in ubuntu trusty (14.04).
 > when i do, i get:
 >     $ nasd -aa
 >     Network Audio System Release 1.9.4
 >     Network Audio System Release 1.9.4
 >     Init: Output open(/dev/dsp) failed: Input/output error
 > 
 >     Fatal server error:
 >     could not create audio connection block info
 > 
 > 
 > osspd is OSS Proxy v1.3.2
 > 
 > since i figured there might be a changelog or something that indicated
 > a recent fix, i downloaded the ossp source.
 > 
 > i didn't try building the daemon, but i did build osstest.c.  when
 > i run osstest, i get the same error:
 > 
 >     $ osstest
 >     test_open@122 test succeeded (mixerfd >= 0)
 >     test_open@131 test failed (ro_fd >= 0): Input/output error
 >     test_open@139 test failed (wo_fd >= 0): Input/output error
 >     test_open@147 test failed (rw_fd >= 0): Input/output error
 >     test_mixer@162 test succeeded (ret >= 0)
 >     Mixer id: OSS Proxy
 >     Name: Mixer
 >     Tests: 3 errors 2 success
 > 
 > any ideas?
 > 
 > this is a fresh ubuntu install, though i admit i've churned a bit
 > installing and removing various OSS compatibility packages in an
 > attempt to get nasd to run.  currently i've removed oss-compat, alsa-oss,
 > and even alsa-base.  pulseaudio is installed.
 > 
 > paul
 > =----------------------
 >  paul fox, pg...@fo... (arlington, ma, where it's 81.3 degrees)
 > 
 > ------------------------------------------------------------------------------
 > _______________________________________________
 > osspd-users mailing list
 > oss...@li...
 > https://lists.sourceforge.net/lists/listinfo/osspd-users

=----------------------
 paul fox, pg...@fo... (arlington, ma, where it's 81.5 degrees)

[OSS Proxy] EIO from osspd

[Paul F. <pg...@fo...>]

hi --

i'm trying to run nasd on osspd in ubuntu trusty (14.04).
when i do, i get:
    $ nasd -aa
    Network Audio System Release 1.9.4
    Network Audio System Release 1.9.4
    Init: Output open(/dev/dsp) failed: Input/output error

    Fatal server error:
    could not create audio connection block info


osspd is OSS Proxy v1.3.2

since i figured there might be a changelog or something that indicated
a recent fix, i downloaded the ossp source.

i didn't try building the daemon, but i did build osstest.c.  when
i run osstest, i get the same error:

    $ osstest
    test_open@122 test succeeded (mixerfd >= 0)
    test_open@131 test failed (ro_fd >= 0): Input/output error
    test_open@139 test failed (wo_fd >= 0): Input/output error
    test_open@147 test failed (rw_fd >= 0): Input/output error
    test_mixer@162 test succeeded (ret >= 0)
    Mixer id: OSS Proxy
    Name: Mixer
    Tests: 3 errors 2 success

any ideas?

this is a fresh ubuntu install, though i admit i've churned a bit
installing and removing various OSS compatibility packages in an
attempt to get nasd to run.  currently i've removed oss-compat, alsa-oss,
and even alsa-base.  pulseaudio is installed.

paul
=----------------------
 paul fox, pg...@fo... (arlington, ma, where it's 81.3 degrees)

[OSS Proxy] gbsplay playback is messed up

[Ralf J. <po...@ra...>]

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)

Re: [OSS Proxy] Problems with osspd and recent Gentoo

[Ralf J. <po...@ra...>]

Hi,

> So..
> 1. Yup
> 2. It's not a module, but build into the kernel, so yes (I guess that
> shouldn't be a problem)
> 3. No /dev/dsp or mixer. OSS is removed, alsa emulation is disabled

I don't know about built-in cuse, but I agree it shouldn't be a problem.
Though maybe it's worth a try...


> 
> So here's strace output..
> 
[...]
Comparing this to the output on my machine doesn't show any significant
difference until

> fuse: fuse_remove_signal_handlers: unknown session
> futex(0x7fff8fe59940, FUTEX_WAIT_PRIVATE, 0, NULL) = -1 EAGAIN

Weird enough, that error is after the print... but I have a very similar
call to futex() and it's succeeding (and it's the last thing happening,
actually).
Also, your output shows exactly the same behaviour that I observe when
calling osspd with osspd already running. In the absence of a better
theory, this looks to me as if something already took these major/minor
numbers. You don't happen to have SOUND_OSS_CORE_PRECLAIM enabled in the
kernel?

I had the same problem on Debian when I had "oss-compat" installed, so I
added the following to /etc/modprobe.d/osspd.conf:

  blacklist snd-pcm-oss
  blacklist snd-mixer-oss
  blacklist snd-seq-oss

I suppose there's nothing in any logfiles?
In particular, I get the following in dmesg when the major/minor numbers
are already claimed:

  CUSE: failed to register chrdev region

Did you use other fuse applications successfully? (I don't know any
other cuse application or I would ask about that.)

= Some more ideas in case none of the above applies =

The communication with fuse is not really visible in the strace though,
that seems to work through magic mmaps - and it looks like it's failing
somewhere there.
Could you insert something like

  if (rc) {
    log_msg(OSSP_LOG_CRIT, "fuse_session_loop_mt returned %d", rc);
  }

after "rc = fuse_session_loop_mt(se);" in cuse_worker in osspd.c?

It may also be interesting to learn more about what's actually happening
in osspd (I hoped to see that with strace, but that did not work out).
Maybe ltrace is more informative? The last resort would be to step
through this with gdb.

Disclaimer: I'm guessing here as much as you are, and it's not like I
know how to use cuse or fuse - I'm just the Debian package maintainer.

Kind regards
Ralf

[OSS Proxy] Problems with osspd and recent Gentoo

[Taras R. <nor...@gm...>]

Hi again

So..
1. Yup
2. It's not a module, but build into the kernel, so yes (I guess that
shouldn't be a problem)
3. No /dev/dsp or mixer. OSS is removed, alsa emulation is disabled

So here's strace output..


execve("/usr/sbin/osspd", ["osspd", "-f", "-v"], [/* 54 vars */]) = 0
brk(0)                                  = 0x10f5000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fedd08d4000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=143154, ...}) = 0
mmap(NULL, 143154, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fedd08b1000
close(3)                                = 0
open("/usr/lib64/libfuse.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0}\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=222320, ...}) = 0
mmap(NULL, 2317768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7fedd047f000
mprotect(0x7fedd04a3000, 2097152, PROT_NONE) = 0
mmap(0x7fedd06a3000, 73728, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x24000) = 0x7fedd06a3000
close(3)                                = 0
open("/lib64/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`#\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=31536, ...}) = 0
mmap(NULL, 2128912, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7fedd0277000
mprotect(0x7fedd027e000, 2093056, PROT_NONE) = 0
mmap(0x7fedd047d000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7fedd047d000
close(3)                                = 0
open("/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200p\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=141203, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fedd08b0000
mmap(NULL, 2217072, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7fedd0059000
mprotect(0x7fedd0071000, 2097152, PROT_NONE) = 0
mmap(0x7fedd0271000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x18000) = 0x7fedd0271000
mmap(0x7fedd0273000, 13424, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fedd0273000
close(3)                                = 0
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\33\2\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1729704, ...}) = 0
mmap(NULL, 3836360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7fedcfcb0000
mprotect(0x7fedcfe50000, 2093056, PROT_NONE) = 0
mmap(0x7fedd004f000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19f000) = 0x7fedd004f000
mmap(0x7fedd0055000, 14792, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fedd0055000
close(3)                                = 0
open("/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\16\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=14416, ...}) = 0
mmap(NULL, 2109712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x7fedcfaac000
mprotect(0x7fedcfaae000, 2097152, PROT_NONE) = 0
mmap(0x7fedcfcae000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fedcfcae000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fedd08af000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fedd08ae000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fedd08ad000
arch_prctl(ARCH_SET_FS, 0x7fedd08ae700) = 0
mprotect(0x7fedd004f000, 16384, PROT_READ) = 0
mprotect(0x7fedcfcae000, 4096, PROT_READ) = 0
mprotect(0x7fedd0271000, 4096, PROT_READ) = 0
mprotect(0x7fedd047d000, 4096, PROT_READ) = 0
mprotect(0x7fedd06a3000, 69632, PROT_READ) = 0
mprotect(0x609000, 4096, PROT_READ)     = 0
mprotect(0x7fedd08d5000, 4096, PROT_READ) = 0
munmap(0x7fedd08b1000, 143154)          = 0
set_tid_address(0x7fedd08ae9d0)         = 13087
set_robust_list(0x7fedd08ae9e0, 24)     = 0
futex(0x7fff8fe5ab60, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fff8fe5ab60, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME,
1, NULL, 7fedd08ae700) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0x7fedd005fa60, [], SA_RESTORER|SA_SIGINFO,
0x7fedd00697b0}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x7fedd005fb00, [],
SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7fedd00697b0}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
brk(0)                                  = 0x10f5000
brk(0x1116000)                          = 0x1116000
write(2, "osspd: OSS Proxy v1.3.2 (C) 2008"..., 67osspd: OSS Proxy
v1.3.2 (C) 2008-2010 by Tejun Heo <te...@su...>
) = 67
rt_sigaction(SIGPIPE, {SIG_IGN, [], SA_RESTORER, 0x7fedd00697b0}, NULL, 8) = 0
readlink("/proc/self/exe", "/usr/sbin/osspd", 4095) = 15
stat("/usr/sbin/ossp-padsp", {st_mode=S_IFREG|0755, st_size=40280, ...}) = 0
mmap(NULL, 8392704, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fedcf2ab000
mprotect(0x7fedcf2ab000, 4096, PROT_NONE) = 0
clone(child_stack=0x7fedcfaaaff0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7fedcfaab9d0, tls=0x7fedcfaab700,
child_tidptr=0x7fedcfaab9d0) = 13088
epoll_create(128)                       = 3
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
mmap(NULL, 8392704, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fedceaaa000
mprotect(0x7fedceaaa000, 4096, PROT_NONE) = 0
clone(child_stack=0x7fedcf2a9ff0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7fedcf2aa9d0, tls=0x7fedcf2aa700,
child_tidptr=0x7fedcf2aa9d0) = 13089
mmap(NULL, 8392704, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fedce2a9000
mprotect(0x7fedce2a9000, 4096, PROT_NONE) = 0
clone(child_stack=0x7fedceaa8ff0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7fedceaa99d0, tls=0x7fedceaa9700,
child_tidptr=0x7fedceaa99d0) = 13090
open("/dev/null", O_RDWR)               = 4
close(4)                                = 0
getuid()                                = 0
open("/dev/cuse", O_RDWR)               = 4
rt_sigaction(SIGHUP, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGHUP, {0x7fedd0494640, [], SA_RESTORER,
0x7fedd00697b0}, NULL, 8) = 0
rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {0x7fedd0494640, [], SA_RESTORER,
0x7fedd00697b0}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {0x7fedd0494640, [], SA_RESTORER,
0x7fedd00697b0}, NULL, 8) = 0
rt_sigaction(SIGPIPE, NULL, {SIG_IGN, [], SA_RESTORER, 0x7fedd00697b0}, 8) = 0
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
open("/dev/null", O_RDWR)               = 5
close(5)                                = 0
getuid()                                = 0
open("/dev/cuse", O_RDWR)               = 5
rt_sigaction(SIGHUP, NULL, {0x7fedd0494640, [], SA_RESTORER,
0x7fedd00697b0}, 8) = 0
rt_sigaction(SIGINT, NULL, {0x7fedd0494640, [], SA_RESTORER,
0x7fedd00697b0}, 8) = 0
rt_sigaction(SIGTERM, NULL, {0x7fedd0494640, [], SA_RESTORER,
0x7fedd00697b0}, 8) = 0
rt_sigaction(SIGPIPE, NULL, {SIG_IGN, [], SA_RESTORER, 0x7fedd00697b0}, 8) = 0
fcntl(5, F_SETFD, FD_CLOEXEC)           = 0
open("/dev/null", O_RDWR)               = 6
close(6)                                = 0
getuid()                                = 0
open("/dev/cuse", O_RDWR)               = 6
rt_sigaction(SIGHUP, NULL, {0x7fedd0494640, [], SA_RESTORER,
0x7fedd00697b0}, 8) = 0
rt_sigaction(SIGINT, NULL, {0x7fedd0494640, [], SA_RESTORER,
0x7fedd00697b0}, 8) = 0
rt_sigaction(SIGTERM, NULL, {0x7fedd0494640, [], SA_RESTORER,
0x7fedd00697b0}, 8) = 0
rt_sigaction(SIGPIPE, NULL, {SIG_IGN, [], SA_RESTORER, 0x7fedd00697b0}, 8) = 0
fcntl(6, F_SETFD, FD_CLOEXEC)           = 0
write(2, "osspd: Creating dsp (14:3), adsp"..., 55osspd: Creating dsp
(14:3), adsp (14:12), mixer (14:0)
) = 55
mmap(NULL, 8392704, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fedcdaa8000
mprotect(0x7fedcdaa8000, 4096, PROT_NONE) = 0
clone(child_stack=0x7fedce2a7ff0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7fedce2a89d0, tls=0x7fedce2a8700,
child_tidptr=0x7fedce2a89d0) = 13091
mmap(NULL, 8392704, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fedcd2a7000
mprotect(0x7fedcd2a7000, 4096, PROT_NONE) = 0
clone(child_stack=0x7fedcdaa6ff0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7fedcdaa79d0, tls=0x7fedcdaa7700,
child_tidptr=0x7fedcdaa79d0) = 13094
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x7fedd0846000
rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT TERM], [], 8) = 0
mmap(NULL, 8392704, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7fedbeffe000
mprotect(0x7fedbeffe000, 4096, PROT_NONE) = 0
clone(child_stack=0x7fedbf7fdff0,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7fedbf7fe9d0, tls=0x7fedbf7fe700,
child_tidptr=0x7fedbf7fe9d0) = 13099
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
fuse: fuse_remove_signal_handlers: unknown session
futex(0x7fff8fe59940, FUTEX_WAIT_PRIVATE, 0, NULL) = -1 EAGAIN
(Resource temporarily unavailable)
tgkill(13087, 13099, SIGRTMIN)          = 0
tgkill(13087, 13101, SIGRTMINfuse: fuse_remove_signal_handlers: unknown session
)          = 0
munmap(0x7fedd0846000, 139264)          = 0
munmap(0x7fedccaa6000, 8392704)         = 0
open("/proc/sys/vm/overcommit_memory", O_RDONLY|O_CLOEXEC) = 4
read(4, "0", 1)                         = 1
close(4)                                = 0
madvise(0x7fedc8022000, 4096, MADV_DONTNEED) = 0
rt_sigaction(SIGHUP, NULL, {0x7fedd0494640, [], SA_RESTORER,
0x7fedd00697b0}, 8) = 0
rt_sigaction(SIGINT, NULL, {0x7fedd0494640, [], SA_RESTORER,
0x7fedd00697b0}, 8) = 0
rt_sigaction(SIGTERM, NULL, {0x7fedd0494640, [], SA_RESTORER,
0x7fedd00697b0}, 8) = 0
rt_sigaction(SIGPIPE, NULL, {SIG_IGN, [], SA_RESTORER, 0x7fedd00697b0}, 8) = 0
close(6)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

Re: [OSS Proxy] Problems with osspd and recent Gentoo

[Ralf J. <po...@ra...>]

Hi,

> Well..since I had moved from OSS4 to alsa/pulseaudio (because of the
> unsupported USB sound card), I started to look for a way to get some
> old games working with my hardware. Alsa oss emulation was working
> well, but i haven't figured a way how to use my external soundcard
> with it (but thats way out of topic..). osspd seemed a great solution,
> but it's just not working with my OS which is x64 system with 3.13.7
> kernel and fuse lib 2.9.3. Output doesn't show much here..

Welcome to the osspd list :)
I am using a very similar setup (linux 3.13.7, Debian amd64, libfuse
2.9.2), so this should really be working. But as you discovered, the
error reporting of osspd is... improvable.

> ./osspd --timestamp -f -v
> <00000000> osspd: OSS Proxy v1.3.2 (C) 2008-2010 by Tejun Heo <te...@su...>
> <00000001> osspd: Creating dsp (14:3), adsp (14:12), mixer (14:0)
> fuse: fuse_remove_signal_handlers: unknown session
> fuse: fuse_remove_signal_handlers: unknown session
> 
> sometimes just
> 
> ./osspd --timestamp -f -v
> <00000000> osspd: OSS Proxy v1.3.2 (C) 2008-2010 by Tejun Heo <te...@su...>
> <00000001> osspd: Creating dsp (14:3), adsp (14:12), mixer (14:0)
> 
> and that's it..nothing. the program just closes silently
> I haven't even got an idea where should I start digging..so at least
> some advice about that would be great =)

Some questions to start with:
* Did you run this as root?
* Did you load the cuse module beforehand, and check that it
  loaded successfully ("lsmod | grep cuse")?
* Do the device files already exist? The OSS module must be unloaded,
  of course, and no other instance of osspd must be running.
  I am getting exactly the errors you are describing when running
  osspd here again, while it is already running in the background.
  ("ls /dev/{*dsp,mixer} -lah", "pidof osspd", "lsmod | grep oss")

If the answer to the above is yes/yes/no, please run osspd with strace,
that should give a better indication what's failing:

  strace osspd -f -v 2> osspd-strace

Kind regards
Ralf

[OSS Proxy] Problems with osspd and recent Gentoo

[Taras R. <nor...@gm...>]

Hi

Well..since I had moved from OSS4 to alsa/pulseaudio (because of the
unsupported USB sound card), I started to look for a way to get some
old games working with my hardware. Alsa oss emulation was working
well, but i haven't figured a way how to use my external soundcard
with it (but thats way out of topic..). osspd seemed a great solution,
but it's just not working with my OS which is x64 system with 3.13.7
kernel and fuse lib 2.9.3. Output doesn't show much here..

./osspd --timestamp -f -v
<00000000> osspd: OSS Proxy v1.3.2 (C) 2008-2010 by Tejun Heo <te...@su...>
<00000001> osspd: Creating dsp (14:3), adsp (14:12), mixer (14:0)
fuse: fuse_remove_signal_handlers: unknown session
fuse: fuse_remove_signal_handlers: unknown session

sometimes just

./osspd --timestamp -f -v
<00000000> osspd: OSS Proxy v1.3.2 (C) 2008-2010 by Tejun Heo <te...@su...>
<00000001> osspd: Creating dsp (14:3), adsp (14:12), mixer (14:0)

and that's it..nothing. the program just closes silently
I haven't even got an idea where should I start digging..so at least
some advice about that would be great =)

[OSS Proxy] Lots of defunct processes

[David W. <da...@da...>]

After using my laptop for a few hours I checked ps and found dozens of 
[ossp-padsp] <defunct>. Also is seems to spawn an extra ossp-padsp
every time I start an app that uses osspd.

Is there a way to avoid this happening?

-Dave

Re: [OSS Proxy] Build failure on slackware 14.1

[David W. <da...@da...>]

On (08/02/14 15:50), Ralf Jung <po...@ra...> put forth the proposition:
>Hi,
>
>> Ok. I managed to fix it by running osspd asmy user rather than root.
>>
>> Problem now is that the sound cuts off 1/2 second or so from the
>> end with that gst-launch command. When running Unreal Tournament (1999
>> version) the sound only comes through at intervals and is very choppy.
>Do you use the PulseAudio or the Alsa backend of osspd? The latter does
>not work properly here, either, but with PA it works great.

I'm using alsa at the moment since slackware doesn't come with pulse
by default and I didn't fancy learning how to use a new api. Alsa
seems to work fine for my needs at the moment.

Dave

Re: [OSS Proxy] Build failure on slackware 14.1

[David W. <da...@da...>]

On (08/02/14 14:25), Dave Woodfall <da...@da...> put forth the proposition:
>On (08/02/14 13:59), Dave Woodfall <da...@da...> put forth the proposition:
>>On (08/02/14 11:50), Ralf Jung <po...@ra...> put forth the proposition:
>>>Hi,
>>>
>>>> Hi, I'm trying to build on slackware 14.1 and I've tried building
>>>> against fuse 2.8.5 and 2.9.3. These are my build options/command:
>>>>
>>>> OSSPD_CFLAGS="$SLKCFLAGS -D_FILE_OFFSET_BITS=64" \
>>>> OSSPD_LDFLAGS="-I/usr/include/fuse" \
>>>> make osspd
>>>This does not make much sense, why do you pass "-I" to the linker? I
>>>suppose this should rather be "-lfuse" or similar.
>>>However, none of this should be necessary, osspd uses pkg-config to find
>>>the libraries.
>>>
>>>$ pkg-config --libs fuse
>>>-pthread -lfuse
>>
>>For some reason it wasn't picking up where the fuse files were located.
>>
>>I managed to get it to build and run now (I had to change the #include
>>lines that reference fuse to fuse/fuse_whatever.h).
>>
>>Now I can play sounds as root but as user I'm getting permission
>>denied:
>>
>>gst-launch-0.10 filesrc location=/home/david/sounds/chat2.wav ! decodebin2 ! audioconvert ! audioresample ! osssink device=/dev/dsp
>>Setting pipeline to PAUSED ...
>>ERROR: Pipeline doesn't want to pause.
>>ERROR: from element /GstPipeline:pipeline0/GstOssSink:osssink0: Could not open audio device for playback. You don't have permission to open the device.
>>Additional debug info:
>>gstosssink.c(408): gst_oss_sink_open (): /GstPipeline:pipeline0/GstOssSink:osssink0:
>>system error: Permission denied
>>Setting pipeline to NULL ...
>>Freeing pipeline ...
>>
>>I've been following this:
>>
>>https://fedoraproject.org/wiki/Features/OSSProxy
>>
>>I'm in the audio and cuse groups and I even tried chmoding /dev/dsp etc a+rw,
>>then chowning as david:users but nothing seems to work.
>
>Ok. I managed to fix it by running osspd asmy user rather than root.
>
>Problem now is that the sound cuts off 1/2 second or so from the
>end with that gst-launch command. When running Unreal Tournament (1999
>version) the sound only comes through at intervals and is very choppy.

Also fixed by switching to generic audio from ALAudio in UT.

Seems to work great. Thanks for a nice application. I've been looking
for a solution to this since I got my T420.

Cheers

Re: [OSS Proxy] Build failure on slackware 14.1

[Ralf J. <po...@ra...>]

Hi,

> Ok. I managed to fix it by running osspd asmy user rather than root.
> 
> Problem now is that the sound cuts off 1/2 second or so from the
> end with that gst-launch command. When running Unreal Tournament (1999
> version) the sound only comes through at intervals and is very choppy.
Do you use the PulseAudio or the Alsa backend of osspd? The latter does
not work properly here, either, but with PA it works great.

Kind regards
Ralf

Re: [OSS Proxy] Build failure on slackware 14.1

[David W. <da...@da...>]

On (08/02/14 13:59), Dave Woodfall <da...@da...> put forth the proposition:
>On (08/02/14 11:50), Ralf Jung <po...@ra...> put forth the proposition:
>>Hi,
>>
>>> Hi, I'm trying to build on slackware 14.1 and I've tried building
>>> against fuse 2.8.5 and 2.9.3. These are my build options/command:
>>>
>>> OSSPD_CFLAGS="$SLKCFLAGS -D_FILE_OFFSET_BITS=64" \
>>> OSSPD_LDFLAGS="-I/usr/include/fuse" \
>>> make osspd
>>This does not make much sense, why do you pass "-I" to the linker? I
>>suppose this should rather be "-lfuse" or similar.
>>However, none of this should be necessary, osspd uses pkg-config to find
>>the libraries.
>>
>>$ pkg-config --libs fuse
>>-pthread -lfuse
>
>For some reason it wasn't picking up where the fuse files were located.
>
>I managed to get it to build and run now (I had to change the #include
>lines that reference fuse to fuse/fuse_whatever.h).
>
>Now I can play sounds as root but as user I'm getting permission
>denied:
>
>gst-launch-0.10 filesrc location=/home/david/sounds/chat2.wav ! decodebin2 ! audioconvert ! audioresample ! osssink device=/dev/dsp
>Setting pipeline to PAUSED ...
>ERROR: Pipeline doesn't want to pause.
>ERROR: from element /GstPipeline:pipeline0/GstOssSink:osssink0: Could not open audio device for playback. You don't have permission to open the device.
>Additional debug info:
>gstosssink.c(408): gst_oss_sink_open (): /GstPipeline:pipeline0/GstOssSink:osssink0:
>system error: Permission denied
>Setting pipeline to NULL ...
>Freeing pipeline ...
>
>I've been following this:
>
>https://fedoraproject.org/wiki/Features/OSSProxy
>
>I'm in the audio and cuse groups and I even tried chmoding /dev/dsp etc a+rw,
>then chowning as david:users but nothing seems to work.

Ok. I managed to fix it by running osspd asmy user rather than root.

Problem now is that the sound cuts off 1/2 second or so from the
end with that gst-launch command. When running Unreal Tournament (1999
version) the sound only comes through at intervals and is very choppy.

Re: [OSS Proxy] Build failure on slackware 14.1

[David W. <da...@da...>]

On (08/02/14 11:50), Ralf Jung <po...@ra...> put forth the proposition:
>Hi,
>
>> Hi, I'm trying to build on slackware 14.1 and I've tried building
>> against fuse 2.8.5 and 2.9.3. These are my build options/command:
>>
>> OSSPD_CFLAGS="$SLKCFLAGS -D_FILE_OFFSET_BITS=64" \
>> OSSPD_LDFLAGS="-I/usr/include/fuse" \
>> make osspd
>This does not make much sense, why do you pass "-I" to the linker? I
>suppose this should rather be "-lfuse" or similar.
>However, none of this should be necessary, osspd uses pkg-config to find
>the libraries.
>
>$ pkg-config --libs fuse
>-pthread -lfuse

For some reason it wasn't picking up where the fuse files were located.

I managed to get it to build and run now (I had to change the #include
lines that reference fuse to fuse/fuse_whatever.h).

Now I can play sounds as root but as user I'm getting permission
denied:

gst-launch-0.10 filesrc location=/home/david/sounds/chat2.wav ! decodebin2 ! audioconvert ! audioresample ! osssink device=/dev/dsp
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstOssSink:osssink0: Could not open audio device for playback. You don't have permission to open the device.
Additional debug info:
gstosssink.c(408): gst_oss_sink_open (): /GstPipeline:pipeline0/GstOssSink:osssink0:
system error: Permission denied
Setting pipeline to NULL ...
Freeing pipeline ...

I've been following this:

https://fedoraproject.org/wiki/Features/OSSProxy

I'm in the audio and cuse groups and I even tried chmoding /dev/dsp etc a+rw,
then chowning as david:users but nothing seems to work.

Any ideas?

Re: [OSS Proxy] Build failure on slackware 14.1

[Ralf J. <po...@ra...>]

Hi,

> Hi, I'm trying to build on slackware 14.1 and I've tried building
> against fuse 2.8.5 and 2.9.3. These are my build options/command:
> 
> OSSPD_CFLAGS="$SLKCFLAGS -D_FILE_OFFSET_BITS=64" \
> OSSPD_LDFLAGS="-I/usr/include/fuse" \
> make osspd
This does not make much sense, why do you pass "-I" to the linker? I
suppose this should rather be "-lfuse" or similar.
However, none of this should be necessary, osspd uses pkg-config to find
the libraries.

$ pkg-config --libs fuse
-pthread -lfuse

Kind regards
Ralf

[OSS Proxy] Build failure on slackware 14.1

[David W. <da...@da...>]

Hi, I'm trying to build on slackware 14.1 and I've tried building
against fuse 2.8.5 and 2.9.3. These are my build options/command:

OSSPD_CFLAGS="$SLKCFLAGS -D_FILE_OFFSET_BITS=64" \
OSSPD_LDFLAGS="-I/usr/include/fuse" \
make osspd

Fails with:

/tmp/cccY3XtV.o: In function `ioctl_prep_uarg':
osspd.c:(.text+0x314): undefined reference to `fuse_reply_ioctl_retry'
/tmp/cccY3XtV.o: In function `notify_poller':
osspd.c:(.text+0x76e): undefined reference to `fuse_lowlevel_notify_poll'
osspd.c:(.text+0x77a): undefined reference to `fuse_pollhandle_destroy'
/tmp/cccY3XtV.o: In function `setup_ossp_cuse':
osspd.c:(.text+0x91f): undefined reference to `cuse_lowlevel_setup'
osspd.c:(.text+0x931): undefined reference to `fuse_session_next_chan'
osspd.c:(.text+0x939): undefined reference to `fuse_chan_fd'
osspd.c:(.text+0x9a8): undefined reference to `cuse_lowlevel_teardown'
/tmp/cccY3XtV.o: In function `cuse_worker':
osspd.c:(.text+0x9ba): undefined reference to `fuse_session_loop_mt'
osspd.c:(.text+0x9c4): undefined reference to `cuse_lowlevel_teardown'
/tmp/cccY3XtV.o: In function `mixer_open':
osspd.c:(.text+0xd8f): undefined reference to `fuse_req_ctx'
osspd.c:(.text+0xdc9): undefined reference to `fuse_reply_open'
osspd.c:(.text+0xe0b): undefined reference to `fuse_reply_err'
osspd.c:(.text+0xe29): undefined reference to `fuse_reply_err'
/tmp/cccY3XtV.o: In function `exec_cmd.constprop.7':
osspd.c:(.text+0x2138): undefined reference to `pthread_mutex_trylock'
/tmp/cccY3XtV.o: In function `dsp_read':
osspd.c:(.text+0x2375): undefined reference to `fuse_reply_err'
osspd.c:(.text+0x242a): undefined reference to `fuse_reply_buf'
/tmp/cccY3XtV.o: In function `dsp_write':
osspd.c:(.text+0x24a2): undefined reference to `fuse_reply_err'
osspd.c:(.text+0x252c): undefined reference to `fuse_reply_write'
/tmp/cccY3XtV.o: In function `dsp_poll':
osspd.c:(.text+0x2626): undefined reference to `fuse_pollhandle_destroy'
osspd.c:(.text+0x2665): undefined reference to `fuse_reply_poll'
osspd.c:(.text+0x2681): undefined reference to `fuse_reply_err'
/tmp/cccY3XtV.o: In function `mixer_do_ioctl':
osspd.c:(.text+0x2818): undefined reference to `fuse_reply_ioctl'
osspd.c:(.text+0x289e): undefined reference to `fuse_reply_ioctl'
osspd.c:(.text+0x2968): undefined reference to `fuse_reply_ioctl'
osspd.c:(.text+0x2a22): undefined reference to `fuse_reply_ioctl'
osspd.c:(.text+0x2c74): undefined reference to `fuse_reply_ioctl'
/tmp/cccY3XtV.o:osspd.c:(.text+0x2ca6): more undefined references to `fuse_reply_ioctl' follow
/tmp/cccY3XtV.o: In function `mixer_do_ioctl':
osspd.c:(.text+0x2cb9): undefined reference to `fuse_reply_err'
/tmp/cccY3XtV.o: In function `dsp_ioctl':
osspd.c:(.text+0x2dea): undefined reference to `fuse_reply_ioctl'
osspd.c:(.text+0x2fb1): undefined reference to `fuse_reply_ioctl'
osspd.c:(.text+0x300c): undefined reference to `fuse_reply_ioctl'
osspd.c:(.text+0x3158): undefined reference to `fuse_reply_err'
osspd.c:(.text+0x31d8): undefined reference to `fuse_reply_ioctl'
osspd.c:(.text+0x342c): undefined reference to `fuse_reply_ioctl'
/tmp/cccY3XtV.o: In function `dsp_open':
osspd.c:(.text+0x350a): undefined reference to `fuse_req_ctx'
osspd.c:(.text+0x3566): undefined reference to `fuse_reply_err'
osspd.c:(.text+0x36ae): undefined reference to `fuse_reply_open'
/tmp/cccY3XtV.o: In function `mixer_release':
osspd.c:(.text+0xee1): undefined reference to `fuse_reply_err'
osspd.c:(.text+0xef2): undefined reference to `fuse_reply_err'
/tmp/cccY3XtV.o: In function `dsp_release':
osspd.c:(.text+0x1191): undefined reference to `fuse_reply_err'
osspd.c:(.text+0x11a2): undefined reference to `fuse_reply_err'
/tmp/cccY3XtV.o: In function `mixer_ioctl':
osspd.c:(.text+0x34e7): undefined reference to `fuse_reply_err'
/tmp/cccY3XtV.o: In function `main':
osspd.c:(.text.startup+0x90): undefined reference to `fuse_opt_parse'
osspd.c:(.text.startup+0x11b): undefined reference to `fuse_opt_add_arg'
osspd.c:(.text.startup+0x336): undefined reference to `pthread_create'
osspd.c:(.text.startup+0x3b1): undefined reference to `pthread_create'
osspd.c:(.text.startup+0x3d0): undefined reference to `pthread_create'
osspd.c:(.text.startup+0x4f4): undefined reference to `pthread_create'
osspd.c:(.text.startup+0x51d): undefined reference to `pthread_create'
osspd.c:(.text.startup+0x534): undefined reference to `fuse_session_loop_mt'
osspd.c:(.text.startup+0x53e): undefined reference to `cuse_lowlevel_teardown'
collect2: error: ld returned 1 exit status
make: *** [osspd] Error 1

Any ideas?

TIA

[OSS Proxy] [PATCH] add -pthread

[Ralf J. <po...@ra...>]

Hi,

this patch adds "-pthread" to the compiler and linker flags, which is
actually required as osspd uses pthreads. It's based on a patch in the
Ubuntu package [1], where it supposedly fixed an FTBFS. For some reason,
the program builds all right on my Debian system, but adding the flag is
IMHO still a good idea.

Kind regards
Ralf

[1] https://launchpad.net/ubuntu/+source/osspd

Re: [OSS Proxy] New news since then...

[Steven M. <s.m...@la...>]

Lo,

As you might recall I mentioned before...

> It seems between Ubuntu 11.10 and 12.04 the Ubuntu kernel developers
> merged some changes from an ARM branch with their main branch and
> accidentally regressed-to/inherited a load of kernel options without
> realising.  Despite Ubuntu having totally and completely removed OSS
> (critical to making OSS Proxy work in it's place)... in 12.04 an option
> crept back in...
>
>  CONFIG_SOUND_OSS_CORE_PRECLAIM=y
>
> Which is particularly a problem because it makes sure the device numbers
> for things like /dev/dsp are hogged all the time by the kernel just in
> case you load OSS backwards compatibility... and since the kernel has no
> OSS backwards compatibility at all any more - it's just causing problems
> for OSS emulation software like OSS Proxy.  So now I know at long last I
> wasn't going absolutely batshit crazy, I filed a bug...
>
>  http://bugs.launchpad.net/ubuntu/+source/linux/+bug/1105230

This is basically an update to say that it's been fixed in 13.04 (raring)
for a few weeks now and shown no issues.  Andy has graciously compiled
both 12.04 and 12.10 (precise and quantal) kernels with the fix and I've
tested these work as well.

In other words, both Ubuntu 12.04 LTS and 12.10 will shortly be able to
use OSS Proxy Daemon once again.

If you can't wait for the updated to kernel to appear in the main Ubuntu
repository, then the kernels he compiled for me are available in a comment
in the link above for now.

Tested with SimCity 3000 Unlimited and it worked great.

Maybe with Ubuntu 12.04+ fixed again (lets face it a pretty popular
distribution), we might get some more interest from both users and
developers.

Many thanks to Andy Whitcroft.

Steven

Re: [OSS Proxy] [osspd:bugs] #4 alsap output too fast

[Miklos S. <mi...@sz...>]

On Tue, Feb 5, 2013 at 7:53 PM, Anand Avati <av...@re...> wrote:

>
> splice() would give us zero user-to-kernel copy, but still results in memory
> copies, no?

Splice allows userspace to move pages from one kernel subsystem to
another (disk to network, etc...) without the page being ever copied
or mapped.  Unlike mmap it does not allow access to the *contents* of
the page.

If you do need to access the contents from userspace then the pages
need to be mapped to avoid copies.  If no access is needed to the
contents then mapping the pages just adds unnecessary overhead.

Think of splice as an operation that can move pages to or from a page
array (the pipe) in userspace.

Thanks,
Miklos

Re: [OSS Proxy] [osspd:bugs] #4 alsap output too fast

[Anand A. <av...@re...>]

On 02/05/2013 10:36 AM, Tejun Heo wrote:
> Hey, Miklos.
>
> On Tue, Feb 05, 2013 at 03:41:24PM +0100, Miklos Szeredi wrote:
>> So basically my patch did a custom client side mmap and Linus said
>> that that could be better implemented with shmem.  Server side mmap
>> wasn't involved, that's the part I didn't like about your original
>> approach, so a server side data store/retrieve was added instead and
>> osspd modified to use that.
>>
>> I couldn't find anything wrong with what Linus said.  Of course it may
>> turn out that there's a reason why it won't work, but it doesn't sound
>> too difficult to implement.
>
> Ah, okay, it's about the client side of mmap.
>
>>> So, I was talking with Avati about gluster the other day, which makes
>>> pretty heavy use of FUSE and reportedly hits bottleneck due to the
>>> double data copy on high bandwidth configurations.  We were talking
>>> about ways to reduce data copy.  The only obvious thing to do is
>>> mapping the page cache pages into the server address space for both
>>> page-cached backed and O_DIRECT files, so at least we do have a much
>>> stronger use case for mmapping pages into server address space.  If
>>> direct mmapping is the way to go, I can dust off my old patches.  What
>>> do you think?
>>
>> I think the idea to share pages through memory maps is fundamentally
>> flawed.  Doing zero copy with splice is saner, I think, and there's a
>
> It is a bit cumbersome but I can't see why it would be fundamentally
> flawed.  That said, yeap, I agree splice would be a lot nicer.

[at the risk of hijacking the original thread ...]

splice() would give us zero user-to-kernel copy, but still results in 
memory copies, no?

Even with that, splice() is incompatible with RDMA. It would be awesome 
if a FUSE userspace filesystem could perform RDMA read/write from/to the 
page cache directly by specifying a virtual (mapped) address -- which is 
fundamentally impossible with splice().

I'm exploring options where the fuse userspace filesystem can mmap the 
file like any other process/app from the mount point, but use the 
/dev/fuse channel to set/unset dirty flags -- effectively fulfilling IO 
requests for other apps. Still in very early stage - probably might end 
up as just a wacko idea :-)

Avati

>
>> lot of infrastructure already there in fuse.  And in theory nothing
>> prevents improving that and achieving true zero copy with direct-IO
>> and single-copy with buffered-IO.  BTW you couldn't do server side
>> mapping of O_DIRECT anyway since no page cache is involved with that.
>
> IIRC, the server side created a file serving as backing store for the
> direct mmap area.  quake could play sound through it, so it worked.
> One way or the other, we need to provide an address_space.
>
> Thanks.
>

Re: [OSS Proxy] [osspd:bugs] #4 alsap output too fast

[Tejun H. <tj...@ke...>]

Hey, Miklos.

On Tue, Feb 05, 2013 at 03:41:24PM +0100, Miklos Szeredi wrote:
> So basically my patch did a custom client side mmap and Linus said
> that that could be better implemented with shmem.  Server side mmap
> wasn't involved, that's the part I didn't like about your original
> approach, so a server side data store/retrieve was added instead and
> osspd modified to use that.
> 
> I couldn't find anything wrong with what Linus said.  Of course it may
> turn out that there's a reason why it won't work, but it doesn't sound
> too difficult to implement.

Ah, okay, it's about the client side of mmap.

> > So, I was talking with Avati about gluster the other day, which makes
> > pretty heavy use of FUSE and reportedly hits bottleneck due to the
> > double data copy on high bandwidth configurations.  We were talking
> > about ways to reduce data copy.  The only obvious thing to do is
> > mapping the page cache pages into the server address space for both
> > page-cached backed and O_DIRECT files, so at least we do have a much
> > stronger use case for mmapping pages into server address space.  If
> > direct mmapping is the way to go, I can dust off my old patches.  What
> > do you think?
> 
> I think the idea to share pages through memory maps is fundamentally
> flawed.  Doing zero copy with splice is saner, I think, and there's a

It is a bit cumbersome but I can't see why it would be fundamentally
flawed.  That said, yeap, I agree splice would be a lot nicer.

> lot of infrastructure already there in fuse.  And in theory nothing
> prevents improving that and achieving true zero copy with direct-IO
> and single-copy with buffered-IO.  BTW you couldn't do server side
> mapping of O_DIRECT anyway since no page cache is involved with that.

IIRC, the server side created a file serving as backing store for the
direct mmap area.  quake could play sound through it, so it worked.
One way or the other, we need to provide an address_space.

Thanks.

-- 
tejun