Bug 1076966 - won't detect ALSA output, defaults to wave writer output,
Summary: won't detect ALSA output, defaults to wave writer output,
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mikmod
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-16 20:35 UTC by Charles R. Anderson
Modified: 2014-03-24 06:45 UTC (History)
4 users (show)

Fixed In Version: libmikmod-3.3.6-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-24 06:45:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Output from alsa-info. (17.23 KB, text/plain)
2014-03-16 20:35 UTC, Charles R. Anderson
no flags Details
strace.log (23.94 KB, application/gzip)
2014-03-17 14:18 UTC, Charles R. Anderson
no flags Details

Description Charles R. Anderson 2014-03-16 20:35:18 UTC
Created attachment 875222 [details]
Output from alsa-info.

Description of problem:

mikmod can't detect ALSA output device on Fedora 20.  The output defaults to the wave writer which writes a music.wav to the current directory.

Version-Release number of selected component (if applicable):
mikmod-3.2.5-1.fc20.x86_64
libmikmod-3.3.5-1.fc20.x86_64


How reproducible:
always

Steps to Reproduce:
1. play any mod file

Actual results:

Disk writer (wav) is chosen as the default output device.
A music.wav file is written with the output of the MOD file.

Expected results:
ALSA output should be used by default.

Additional info:

Comment 1 Hans de Goede 2014-03-17 09:21:21 UTC
This is weird, it works fine for me. Do you have permissions on /dev/snd/pcm* ? Note this uses acl's so to check use: "getfacl /dev/snd/pcm*"

Are you starting mikmod from an xterm / gnome-terminal under a gdm login session, or are you ssh-ing in ? ssh-ing in will probably only work if you also have a gdm login session running so that pulseaudio is running and has access to /dev/snd/pcm*

Can you run mikmod through strace and attach the strace log here please ?

IE start it like this:

strace -o strace.log mikmod <somefile.xm>

And then gzip + attach the generated strace.log here ?

Comment 2 Charles R. Anderson 2014-03-17 14:17:03 UTC
Sound works from other programs, including xmp.

getfacl: Removing leading '/' from absolute path names
# file: dev/snd/pcmC0D0c
# owner: root
# group: audio
user::rw-
user:cra:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D0p
# owner: root
# group: audio
user::rw-
user:cra:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D3p
# owner: root
# group: audio
user::rw-
user:cra:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D7p
# owner: root
# group: audio
user::rw-
user:cra:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D8p
# owner: root
# group: audio
user::rw-
user:cra:rw-
group::rw-
mask::rw-
other::---

This might have something to do with it:

open("/lib64/tls/x86_64/libasound.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib64/tls/libasound.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib64/x86_64/libasound.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib64/libasound.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/x86_64/libasound.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/libasound.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/x86_64/libasound.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libasound.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib64/tls/libasound.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib64/libasound.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/libasound.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libasound.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

Comment 3 Charles R. Anderson 2014-03-17 14:18:41 UTC
Created attachment 875512 [details]
strace.log

Output from:

strace -o strace.log mikmod 2nd_pm.s3m
gzip strace.log

with the Output configuration set to ALSA directly, then set to autodetect.

Comment 4 Charles R. Anderson 2014-03-17 14:25:11 UTC
Confirmed that it works if I install alsa-lib-devel:

>sudo yum install /usr/lib64/libasound.so
Loaded plugins: langpacks, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package alsa-lib-devel.x86_64 0:1.0.27.2-2.fc20 will be installed
--> Finished Dependency Resolution
...

Comment 5 Ozkan Sezer 2014-03-20 09:06:13 UTC
This should be fixed upstream now:
http://sourceforge.net/p/mikmod/mercurial/ci/a01ab4c86245145845833bfb9c12a12929c4194d/

I plan on making a new libmikmod-3.3.6 release in a few days.

Comment 6 Hans de Goede 2014-03-20 10:20:05 UTC
Hi,

(In reply to Ozkan Sezer from comment #5)
> This should be fixed upstream now:
> http://sourceforge.net/p/mikmod/mercurial/ci/
> a01ab4c86245145845833bfb9c12a12929c4194d/
> 
> I plan on making a new libmikmod-3.3.6 release in a few days.

Thanks for the heads-up. I'll wait for the new release to fix this then.

Regards,

Hans

Comment 7 Ozkan Sezer 2014-03-21 18:28:13 UTC
New 3.3.6 release is out which should fix the issue reported here.

Comment 8 Hans de Goede 2014-03-22 14:43:56 UTC
(In reply to Ozkan Sezer from comment #7)
> New 3.3.6 release is out which should fix the issue reported here.

Thanks, an updated libmikmod package is on its way to f-20+

Comment 9 Fedora Update System 2014-03-22 15:14:44 UTC
libmikmod-3.3.6-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libmikmod-3.3.6-1.fc20

Comment 10 Fedora Update System 2014-03-24 06:45:01 UTC
libmikmod-3.3.6-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.