I've discussed this with the only technically-compentent MOC user I know of who is still using OSS and he is unable to reproduce your problem on MOC 2.5.2 with OSS 4.2 under FreeBSD 12.0.
It is my strong suspicion that the cause is not within MOC, especially since seeking does not involve the sound subsystem at all. But here are some additional questions which may shine some light:
Is OSS the only audio component in use? In particular, is PulseAudio getting into the act somehow?
Are you running MOC within a terminal emulator under X-Windows? If so, do you see the same problem if you use MOC on a native console?
Hello, thanks for a reply.
I'll try to answer at all questions.
0.
My MOC config
Theme = /home/abishai/.moc/themes/solarized
SeekTime = 5
SilentSeekTime = 20
#SoundDriver = SNDIO
Softmixer_SaveState = yes
1. To say the truth I don't know what softmixer is.
In FreeBSD we have default device, that outputs sound.
abishai@darkstar:~ % mixer
Mixer vol is currently set to 75:75
Mixer pcm is currently set to 100:100
Mixer line is currently set to 1:1
Mixer mic is currently set to 67:67
Mixer mix is currently set to 0:0
Mixer rec is currently set to 0:0
Mixer igain is currently set to 0:0
Mixer ogain is currently set to 0:0
Recording source: mic
Volume is always 45%. When MOC starts, I see 00% in MOC UI. When playing starts it becomes 45%.
If I use > to increase the volume it sets to higher value. Using ] or switch track resets volume to 45.
2. MOC is the only OSS application.
3. Usually, we don't have PulseAudio om FreeBSD as OSS doesn't have ALSA limitations. But I've built SNDIO from OpenBSD. We use SNDIO without daemon, only as client API as it's mapped directory to /dev/dsp
With SNDIO backend ] or automatic next track doesn't resets volume. Manual track switch (when I choose track and hit ENTER button) resets it to 45 back.
> I've discussed this with the only technically-compentent MOC user I know of who is still using OSS and he is unable to reproduce your problem on MOC 2.5.2 with OSS 4.2 under FreeBSD 12.0.
This statement is very suspicious :) I don't think it's possible to determine embedded OSS version in FreeBSD, it was forked in OSS 3 era and never was synced with upstream.
Knowing that the user in question is quite capable of building and installing an upgraded OSS himself and also quite capable of independantly determining the OSS version he uses, I do not question his report myself.
I've done a little more digging and found this post which indicates to me that what you're experiencing is the way it's supposed to work but is controllable via the settings of hw.snd.vpc_0db and hw.snd.vpc_autoreset (as documented in sound(4)).
Contrary to my previous post, MOC does reset the sound driver when seeking in order to flush the unplayed samples still cached downstream, and in the OSS's case this is done by resetting the device which in turn results in the volume being reset to the hw.snd.vpc_0db value if hw.snd.vpc_autoreset is enabled (which it is by default).
There appears to be some dispute in that thread about whether or not triggering such behaviour can be considered a bug in the client application. But, given that most applications are quite capable of controlling the volume themselves, I'd say not.
It would probably be possible to have MOC maintain the volume across a reset and stop/start cycles, but with the availablity of those two settings would you consider it worthwhile?
It's hard to explain, but hw.snd.vpc_0db is not trivial 'default sound volume'. If I set it to 100%, MOC plays with lower volume on 100% than MOC on 100% (set manually) with hw.snd.vpc_0db on default value. It is mentioned in thread as well. So, it's not 'output volume', but some kind of amplification setting (0db level?).
hw.snd.vpc_autoreset looks better. Setting it to 0 solves the issue (leaving me slightly confused as I thought there are pcm and vol presets for volume).
rigiletto@ mentioned that he set mixer_type to software so solve his issue. Do you know what this is? Maybe it's possible to configure mixer type in MOC too?
If I set it to 100%, MOC plays with lower volume on 100% than MOC on 100% (set manually) with hw.snd.vpc_0db on default value.
My understanding (and purely from the reading of the thread I referenced) is that the hw.snd.vpc_0db represents the highest amplification which can be made without clipping. How SNDIO would determine that without pre-processing the whole audio stream I do not know. Also note that it is in decibels while MOC's setting is linear.
If I've got that right, then I'd expect that volume to be lower than what MOC produces at it's 100% volume setting. However, the SNDIO setting would probably result in a more consistant volume across audios recorded/engineered at different levels.
rigiletto@ mentioned that he set mixer_type to software so solve his issue. Do you know what this is? Maybe it's possible to configure mixer type in MOC too?
He's referring here to the MPD configuration file, so I'd suggest consulting the MPD documentation. It's probably saying that amplification should be done in hardware alone, and (also probably) has another "software" setting which specifies amplification by either the sound subsystem or (and possibly a third setting) by MPD itself.
Because MOC is a client application of multiple potential sound subsystems, the volume setting is passed to the sound subsystem for it to implement in its own way. MOC also has a softmixer (to which I referred earlier) the use of which enables MOC to perform the amplification internally.
Okay, I missed that. It would have appeared in my Forum topic index if MegaManSec hadn't reported a new issue on an existing thread. He also indicated it was a very minor issue for him and, given the lack of FreeBSD resources at my command, it probably got shelved.
jcf
Sun, 2019-09-15 19:39
Permalink
That's Weird
I don't run OSS and so can't debug it, but I shall refer it on to someone who does and, hopefully, can.
In the meantime, I'll just ask some initial questions:
Are you using the softmixer at all?
Does it matter what the volume setting was prior to the seek or track change, or is it always 45%?
Are there any other applications using OSS at the same time?
jcf
Tue, 2019-09-17 00:18
Permalink
It's Probably Not MOC
I've discussed this with the only technically-compentent MOC user I know of who is still using OSS and he is unable to reproduce your problem on MOC 2.5.2 with OSS 4.2 under FreeBSD 12.0.
It is my strong suspicion that the cause is not within MOC, especially since seeking does not involve the sound subsystem at all. But here are some additional questions which may shine some light:
Is OSS the only audio component in use? In particular, is PulseAudio getting into the act somehow?
Are you running MOC within a terminal emulator under X-Windows? If so, do you see the same problem if you use MOC on a native console?
abi
Sun, 2019-09-22 12:36
Permalink
Hello, thanks for a reply.
Hello, thanks for a reply.
I'll try to answer at all questions.
0.
My MOC config
Theme = /home/abishai/.moc/themes/solarized
SeekTime = 5
SilentSeekTime = 20
#SoundDriver = SNDIO
Softmixer_SaveState = yes
1. To say the truth I don't know what softmixer is.
In FreeBSD we have default device, that outputs sound.
abishai@darkstar:~ % cat /dev/sndstat
Installed devices:
pcm0: <ATI R6xx (HDMI)> (play)
pcm1: <Realtek ALC1150 (Rear Analog 5.1/2.0)> (play/rec) default
pcm2: <Realtek ALC1150 (Front Analog)> (play/rec)
pcm3: <Realtek ALC1150 (Rear Digital)> (play)
No devices installed from userspace.
abishai@darkstar:~ % mixer
Mixer vol is currently set to 75:75
Mixer pcm is currently set to 100:100
Mixer line is currently set to 1:1
Mixer mic is currently set to 67:67
Mixer mix is currently set to 0:0
Mixer rec is currently set to 0:0
Mixer igain is currently set to 0:0
Mixer ogain is currently set to 0:0
Recording source: mic
Volume is always 45%. When MOC starts, I see 00% in MOC UI. When playing starts it becomes 45%.
If I use > to increase the volume it sets to higher value. Using ] or switch track resets volume to 45.
2. MOC is the only OSS application.
3. Usually, we don't have PulseAudio om FreeBSD as OSS doesn't have ALSA limitations. But I've built SNDIO from OpenBSD. We use SNDIO without daemon, only as client API as it's mapped directory to /dev/dsp
With SNDIO backend ] or automatic next track doesn't resets volume. Manual track switch (when I choose track and hit ENTER button) resets it to 45 back.
4. The same applies to vt console.
abi
Sun, 2019-09-22 12:43
Permalink
I've discussed this with
> I've discussed this with the only technically-compentent MOC user I know of who is still using OSS and he is unable to reproduce your problem on MOC 2.5.2 with OSS 4.2 under FreeBSD 12.0.
This statement is very suspicious :) I don't think it's possible to determine embedded OSS version in FreeBSD, it was forked in OSS 3 era and never was synced with upstream.
jcf
Sun, 2019-09-22 20:12
Permalink
DIY Upgrades
Knowing that the user in question is quite capable of building and installing an upgraded OSS himself and also quite capable of independantly determining the OSS version he uses, I do not question his report myself.
jcf
Sun, 2019-09-22 20:16
Permalink
We Are Not Alone
We Are Not Alone
I've done a little more digging and found this post which indicates to me that what you're experiencing is the way it's supposed to work but is controllable via the settings of
hw.snd.vpc_0dbandhw.snd.vpc_autoreset(as documented insound(4)).Contrary to my previous post, MOC does reset the sound driver when seeking in order to flush the unplayed samples still cached downstream, and in the OSS's case this is done by resetting the device which in turn results in the volume being reset to the
hw.snd.vpc_0dbvalue ifhw.snd.vpc_autoresetis enabled (which it is by default).There appears to be some dispute in that thread about whether or not triggering such behaviour can be considered a bug in the client application. But, given that most applications are quite capable of controlling the volume themselves, I'd say not.
It would probably be possible to have MOC maintain the volume across a reset and stop/start cycles, but with the availablity of those two settings would you consider it worthwhile?
abi
Sun, 2019-09-22 20:48
Permalink
Indeed interesting.
Indeed interesting.
It's hard to explain, but hw.snd.vpc_0db is not trivial 'default sound volume'. If I set it to 100%, MOC plays with lower volume on 100% than MOC on 100% (set manually) with hw.snd.vpc_0db on default value. It is mentioned in thread as well. So, it's not 'output volume', but some kind of amplification setting (0db level?).
hw.snd.vpc_autoreset looks better. Setting it to 0 solves the issue (leaving me slightly confused as I thought there are pcm and vol presets for volume).
rigiletto@ mentioned that he set mixer_type to software so solve his issue. Do you know what this is? Maybe it's possible to configure mixer type in MOC too?
jcf
Sun, 2019-09-22 21:18
Permalink
Big Sounds, Little Sounds, Sounds That Make You Think
My understanding (and purely from the reading of the thread I referenced) is that the
hw.snd.vpc_0dbrepresents the highest amplification which can be made without clipping. How SNDIO would determine that without pre-processing the whole audio stream I do not know. Also note that it is in decibels while MOC's setting is linear.If I've got that right, then I'd expect that volume to be lower than what MOC produces at it's 100% volume setting. However, the SNDIO setting would probably result in a more consistant volume across audios recorded/engineered at different levels.
He's referring here to the MPD configuration file, so I'd suggest consulting the MPD documentation. It's probably saying that amplification should be done in hardware alone, and (also probably) has another "software" setting which specifies amplification by either the sound subsystem or (and possibly a third setting) by MPD itself.
Because MOC is a client application of multiple potential sound subsystems, the volume setting is passed to the sound subsystem for it to implement in its own way. MOC also has a softmixer (to which I referred earlier) the use of which enables MOC to perform the amplification internally.
abi
Sun, 2019-09-22 12:57
Permalink
I've made more searches and
I've made more searches and discovered this thread MegaManSec mentions this magic number too.
jcf
Sun, 2019-09-22 20:13
Permalink
The Risks of Threadjacking
Okay, I missed that. It would have appeared in my Forum topic index if MegaManSec hadn't reported a new issue on an existing thread. He also indicated it was a very minor issue for him and, given the lack of FreeBSD resources at my command, it probably got shelved.