Bug 1149418 - MIDI busted; permission problem with /dev/snd/seq
Summary: MIDI busted; permission problem with /dev/snd/seq
Keywords:
Status: CLOSED DUPLICATE of bug 1147248
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 20
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Orphan Owner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-04 21:13 UTC by Matthew Woehlke
Modified: 2014-11-10 20:02 UTC (History)
12 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-11-10 19:56:05 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Matthew Woehlke 2014-10-04 21:13:58 UTC
Description of problem:
Some time between Fedora 16 and Fedora 20, MIDI via alsa_seq (e.g. QSynth) stopped working due to permission issues with /dev/snd/seq. Specifically, existing users do not have permission to access /dev/snd/seq.

How reproducible:
Always?

Steps to Reproduce:
1. Create a user that does not belong to the 'audio' group
2. Try to start QSynth using the alsa_seq driver

Actual results:
"Qsynth1: Failed to create the MIDI driver (alsa_seq)."

Expected results:
QSynth works, other programs can connect and play MIDI over ALSA.

Additional info:
This was working in Fedora 16. A little while back I updated the system to Fedora 20, and was trying to use QSynth again and ran into the error above. I can work around it by giving everyone access to /dev/snd/seq (chmod go+rw), but that's a mighty big sledgehammer and probably not appropriate as a general solution. Besides, it should ideally work out of the box.

Possibly related: https://bugs.freedesktop.org/show_bug.cgi?id=66861

p.s. JFTR I am *not* using JACK. At all. (In fact, because JACK *completely breaks* audio on my system, and umpteen things have somehow gotten into the habit of starting it when I don't want it, I've had to resort to putting '/usr/bin/true' in my ~/.jackdrc in order to prevent it from starting.)

(Apologies for the component which is quite possibly wrong; I'm really not sure who "owns" this, and being a device, I can't 'rpm -qf' it.)

Comment 1 Jan Synacek 2014-11-10 13:22:58 UTC
How did you upgrade from F16 to F20? That's quite a big step and who knows what might have gotten wrong. Also, does "setenforce 0" help?

Comment 2 Jan Synacek 2014-11-10 15:04:37 UTC
I just tested qsynth on freshly installed and updated F20 and there are no MIDI problems.

systemd-208-26.fc20.x86_64
qsynth-0.3.7-2.fc20.x86_64

Comment 3 Matthew Woehlke 2014-11-10 15:47:58 UTC
I used fedup: 16 -> 17, 17 -> 18, 18 -> 19, 19 -> 20 (yes, I went through all three intervening versions).

I'll have to get back to you on setenforce, but considering the permissions and information I found elsewhere (and that a simple permission change fixes it) I'll be surprised if it makes a difference.

Hrm... you know, I think this might have been fixed already; don't trust me on that until I can get to my other machine to check, but logging in remotely, I'm now seeing:

crw-rw----+ 1 root audio 116,  1 Nov  5 22:43 seq

...which is NOT what I remember the permissions being when I filed the bug. (I do believe I've rebooted the machine since, however, hence the suspicion that it got fixed by some update...)


Bonus: I have another F20 machine that is a *clean install* but that I haven't been running updates on rigorously (and hasn't been rebooted in at least 66 days) that has:

crw-------+ 1 root audio 116,  1 Sep 30 16:43 seq

So it does look strongly like this already got fixed somewhere. If you like I can check what outstanding updates I have on the other machine...

Comment 4 Matthew Woehlke 2014-11-10 15:52:04 UTC
FYI:

System I think is working:
systemd-208-26.fc20.x86_64

System that probably isn't:
systemd-208-22.fc20.x86_64

Comment 5 Michal Schmidt 2014-11-10 19:56:05 UTC

*** This bug has been marked as a duplicate of bug 1147248 ***

Comment 6 Matthew Woehlke 2014-11-10 20:02:13 UTC
Yeah, I'll buy that. Thanks.


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