meter or clipping warning for Record/Broadcast input

Bug #1742499 reported by Ron Ackerman
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Confirmed
Wishlist
Unassigned

Bug Description

Tried 2.1.0 on my live broadcast today. Used 3rd party DSP encoders until that issue is resolved.

1. When a song is loading while song is playing it causes the playing song to stutter. In fact doing anything will cause the song to stutter. If you know of a setting to prevent this that would be great. This is a no go!

2. I drag and drop a lot from a Windows folder I'll search for a song and while searching it causes stuttering.

3. I need to move the wave forms down. This is a skin thing, I'm using Latenight 2.1. See photo.

4. I do like Dark Metal skin there are a lot of features that it has that would be nice in Latenight.

5. The recording is horrible I'll include an audio clip.

Other than that it was okay but I will have to go back to 2.0 because of the stuttering

Revision history for this message
Ron Ackerman (ronack01) wrote :
Revision history for this message
Ron Ackerman (ronack01) wrote :

As you see my mic blocks the wave forms which I have become to rely on. Maybe when the silence killer and end cue's I wont need the waves but for now I need them.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

The recorded track is clipping a lot. Does the Master VU-Meter indicate that as well?

Which Sound API do you use with which buffer size?

Revision history for this message
Ron Ackerman (ronack01) wrote :

Windows Direct Sound. VU-meters were not maxed out they looked fine. I can see the clipping on the recorded waveform via audacity. Maybe add a slider in the record section. I would normally run it at about 75%. I can always add volume to what's recorded after the fact but I can't eliminate clipping.

When I listen to this it's almost as bad as what went over the broadcast using the Mixxx encoder. Which leads me to think that maybe providing a sound adjustment to both the record section and encoder might do the trick. Maybe it's just over driving everything.

Revision history for this message
Be (be.ing) wrote :

> Maybe it's just over driving everything.

That sounds like what is going on. The master output is the same as what is sent to broadcasting and recording, so if you see clipping on the master meters, the broadcast and recording will be clipping too.

Revision history for this message
Ron Ackerman (ronack01) wrote :

However it's not clipping except on the recording and broadcasting. and the meter is not maxed out.

Revision history for this message
Ron Ackerman (ronack01) wrote :

I reinstalled 2.1.0 I was able to get rid of the clipping with system levels and again my master levels were fine. The rumbling is gone for now. I think it's a combination of input / output settings but I don't know. However now nothing going out on the encoder however I can see the meta data. Also it still stutters whenever you do anything on the PC.

I'm willing to work with you on all of this. But I'll have to go back to 2.0 to do my shows.

Revision history for this message
Be (be.ing) wrote :

Are you using the Record/Broadcast input in the Sound Hardware Preferences? If so, then the signal from that input is used unmodified for recording and broadcasting and the master meters in Mixxx do not tell anything about that. I realize now that there is no meter for this signal available in Mixxx, but perhaps we should add one.

Revision history for this message
Ron Ackerman (ronack01) wrote :

YES! Very true and like I said give us a volume control for that signal as well.

Making progress!!!!

Revision history for this message
Be (be.ing) wrote :

I am not sure a gain or volume control for the record/broadcast signal would be useful. If you are using the Record/Broadcast input and the signal is coming into your sound card clipping, there is nothing Mixxx can do to make it not clipping. The level needs to be adjusted before that in hardware, preferably at the sound card input, or if there is no gain control there, at the mixer's output. If your sound card does not have a meter for this input, seeing a meter in Mixxx would help. I think we should break feature freeze for 2.1 to add that meter so users do not keep getting confused, but we would have to break string freeze too to add a tooltip for it. :/ Regardless, I'll be sure to mention this issue in the manual, so thanks for reporting it.

Would there be a use case for a gain knob for the record/broadcast signal when recording/broadcasting Mixxx's internal master mix instead of using the Record/Broadcast input?

Revision history for this message
Ron Ackerman (ronack01) wrote :

I'm sure your correct on that so it's probably not needed. It can always be added at a later date if needed. How about VU-Meter? Something visual?

Any ideas on the stuttering issue? 2.0 doesn't have it.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Be, you are probably right the Record/Broadcast input is pretty useless without an VU-Meter. I think we made the mistake not actually using it during the verification.

Unfortunately adding this during beta is a big feature creep. It has implications to many regions in the Mixxx project.

IMHO a good solution is to make the input inheriting Aux. There is no difference, of capturing an input used for Aux or Broadcasting. We need at least a VU-Meter, a Gain, and a PFL-Feature. A skin friendly solution would be to add an Record/Broadcast routing switch to the Aux decks, for example.

Alternative, we can just remove the Record/Broadcasting input and find a well thought solution for 2.2-alpha.

Ron, why is going back to 2.0 a solution for you? It does not have a Record/Broadcast input.
Can you describe, why you need to route the signal out of Mixxx and back? Which external Hardware do you use?

Revision history for this message
Daniel Schürmann (daschuer) wrote :

> Any ideas on the stuttering issue? 2.0 doesn't have it.

Does the sound output of Mixxx stutter, or just the waveforms? Which buffer size do you use?

Revision history for this message
Be (be.ing) wrote :

I don't understand why you think adding a meter for the Record/Broadcast input would be a big feature creep. It just requires adding an EngineVumeter to EngineMaster, finding a place to show it in the skins (probably next to the recording and broadcasting buttons), and adding a tooltip.

> IMHO a good solution is to make the input inheriting Aux. There is no difference, of capturing an input used for Aux or Broadcasting.

Yes, there is a big difference that would make your proposal very confusing. The auxiliary inputs are for adding another source to Mixxx's master mix. The Record/Broadcast input is not mixed in with the master mix or manipulated in any way by Mixxx. It is only forwarded to the recording and broadcasting encoders to avoid the need for running a separate program like BUTT or Audacity.

Revision history for this message
Ron Ackerman (ronack01) wrote :

Reverting back to 2.0? Mainly because of the stuttering problem. When in Auto-DJ it is really bad when the next song is loading. Also bad if I search for a song using Windows file manager. Click a folder in the tree. etc.

Also I did have the problem where the encoder captured what seemed to be a PFL sound, I was unable to control it. It may have been a setting. My last test I didn't get any sound to the encoder but did to the recorder.

Doing a live radio show it needs to be better to almost flawless. Leaving the problems as my stupid mistakes. Stuttering is a non starter.

Do you think it might be a priority issues. Mixxx needing a higher priority of resources?

Revision history for this message
Daniel Schürmann (daschuer) wrote :

I did not mean to use rout the signal though the engine like the aux channels. I mean, there is no difference between Aux and other input if you look at the hardware, so they should feature the same controls. Only a VU meter is not enough.

It is senseless to discuss if it is a big or a small feature creep. We should be state clearly that it is one, and we should consider all implications wise.

> It just requires ...

The "just" is the issue here. ;-)

Revision history for this message
Ron Ackerman (ronack01) wrote :

Stuttering happens overall. Not only sound but visual on the waveform as well. I can provide an example later.

Revision history for this message
Be (be.ing) wrote :

Please keep discussion about separate issues in separate bugs. It is difficult to stay organized if bugs contain multiple unrelated discussions. If you would like to have a more freeform discussion, Zulip ( https://mixxx.zulipchat.com/ ) may be a better place for that than the bug tracker.

Revision history for this message
Be (be.ing) wrote :

> I mean, there is no difference between Aux and other input if you look at the hardware, so they should feature the same controls. Only a VU meter is not enough.

The use cases are very different so different controls are appropriate. Having similar controls would be confusing.

I think this is all that is needed to implement a meter for the Record/Broadcast input:
* An EngineVumeter in EngineMaster that is used if the Record/Broadcast signal is active
* A ControlObject to communicate to skins whether the Record/Broadcast input is configured
* Add the meter to skins, probably next to the recording and broadcasting buttons
* Add a tooltip for the meter

That is a small set of low risk changes.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

We need PLF and a gain as well.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

It is small, because you want it. A small change is to comment the Recording/Broadcast input in the Hardware preferences. But let's discuss pro and cons of merging a solution instead.

For now, I am for making it right, instead of rushing it in. If we have a finished PR, we can decide into which branch it should be merged.

Revision history for this message
Be (be.ing) wrote :

What would be the use cases for a PFL button or gain knob for the Record/Broadcast input? I cannot think of any. I think they would only add to users' confusion.

summary: - Observations on Live Broadcast 2.1.0
+ meter for Record/Broadcast input
Revision history for this message
Be (be.ing) wrote : Re: meter for Record/Broadcast input

> My last test I didn't get any sound to the encoder but did to the recorder.

The only way this could happen is if recording is enabled but broadcasting is not. The signal sent to each is identical.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

I don't know why, but my line on-board line input is to low. I have to crank up the gain to 6 dB.

The plf input is needed, because you cannot rely on the sound quality only looking at the VU-Meter.
The Mic Mixx might be unbalanced or you have clipping in an early state. Without Plf, you can only record the sound and listen to it later. With a PLF, it is easy to check the sound before going on air.

Revision history for this message
Be (be.ing) wrote :

Okay, so there would be a use case for a gain knob in case the mixer and sound card both provide an inadequate amount of gain. But I am pretty sure there is no use case for adding a PFL button to the Record/Broadcast input. Mixxx's PFL is not used with an external mixer, so it would not be useful. Also, the signal is already being monitored on the speakers from the mixer's main output, so there would not be a point to listening to it in headphones.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

I think it is not a big deal to pass the signal to pfl. And it may save the user for a broken show in odd cases.
He can always very everything is ok with a single mode click, so let's at least consider this.
A good or maybe better alternative would be to listen the sidechain stream in headphones.

Revision history for this message
Ron Ackerman (ronack01) wrote :

Also, the signal is already being monitored on the speakers from the mixer's main output, so there would not be a point to listening to it in headphones.

I don't even have speakers attached to the computer. only headphones attached to the mixer. When I do monitor it I monitor the sound from another computer that's playing the stream. I don't know if other radio DJ's do it that way but it works for me.

Revision history for this message
Be (be.ing) wrote :

> I don't even have speakers attached to the computer. only headphones attached to the mixer.

Right, it doesn't matter whether you're listening on speakers or headphones. The point is you're already listening to that signal so adding a PFL button for it would be useless. There is a cost to adding a PFL button for the Record/Broadcast input. It would clutter the GUI, confuse users, and complicate the EngineMaster code.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Ron has the perfect use case for the Pfl button though. Only on pair of headphones, no speakers, plugged into the Mixxx pfl channel he can listen to everything without pluging the headphones around.

Revision history for this message
Ron Ackerman (ronack01) wrote :

To be honest, I'm thinking about this and I don't know how the PFL would work via software. On headphones via mixer I'm listening the final product before hitting the encoders. Which is a mix of Mixxx and anything that I add via the mixer ie mic's, phone calls, promo hits etc. Maybe others could use the Pre Fader Listen? And at what point in the process would that come into play?

I use it a lot in my live stage mixes to hear one or more inputs.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

You will be able to listen the stream that is passed through the Recording/Broadcasting input before it is encoded for broadcasting. It is basically the same what you can see in the proposed side-stream VU-Meter.

Revision history for this message
Be (be.ing) wrote :

> And at what point in the process would that come into play?

As you described, it wouldn't because the headphones are connected to the mixer, not Mixxx's headphones output. Mixxx's headphone output is useless with an external mixer.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Ron, how do you preview single decks? Which Mixxx outputs are connected to your external Mixer?

With the new side-chain pfl, your headphones can remain in your if you are able to switch them to Mixxx's headphones output. Than you are able to listen to the stream that is actually encoded.

Currently you can only listen to the hardware source stream that is passed back to Mixxx.
The streaming sound may get broken by a loose connection or such between your mixer output and Mixxx's recording/broadcasting input. If we have the proposed PFL position,you can listen to the broadcast sound, and are able to hear such issues.

Revision history for this message
Ron Ackerman (ronack01) wrote :

Ron, how do you preview single decks? Which Mixxx outputs are connected to your external Mixer?

> I don't!

With the new side-chain pfl, your headphones can remain in your if you are able to switch them to Mixxx's headphones output. Than you are able to listen to the stream that is actually encoded.

> Not sure I understand what you're saying here.

Currently you can only listen to the hardware source stream that is passed back to Mixxx.

> I agree!

The streaming sound may get broken by a loose connection or such between your mixer output and Mixxx's recording/broadcasting input.

> I have no loose connections.

If we have the proposed PFL position,you can listen to the broadcast sound, and are able to hear such issues.

> I'll be interested to see this work.

Revision history for this message
Be (be.ing) wrote :

> The streaming sound may get broken by a loose connection or such between your mixer output and Mixxx's recording/broadcasting input. If we have the proposed PFL position,you can listen to the broadcast sound, and are able to hear such issues.

Hearing that issue would not help any more than seeing the meter for the Record/Broadcast signal indicating no input signal. And as Ron has already said, it wouldn't be able to be heard anyway because his headphones are connected to the hardware mixer, not Mixxx's Headphones output.

Revision history for this message
Ron Ackerman (ronack01) wrote :

Had an idea tonight to save me from having to load and unload 2.0 and 2.1.0. I installed 2.1.0 on another computer which is also connected to the same mixer.

I'll be on at 8:30 AM Eastern tomorrow. Unfortunately I'll be using 2.0 and 3rd party encoders. If you want to tune in you can listen at thebluegrassjamboree.com or TuneIn app. 2 hour show!

Revision history for this message
Ron Ackerman (ronack01) wrote :

I downloaded the latest beta after my show today. Tried a few songs and recorded. No stuttering, no clipping. I will try and use the beta for my show on Wednesday at 10:30 AM complete with encoders. I may try the test encoder later. Confidence is HIGH!

Revision history for this message
Ron Ackerman (ronack01) wrote :

I mean test server.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

> Hearing that issue would not help any more than seeing the meter for the Record/Broadcast signal indicating no input signal.

When hearing the sound you can Identify a clipped signal in an early stage, where the signal level in Mixxx is still green for example. We can PFL all soundcard inputs. I do not understand why the Recording/Broadcasting input should be an exception.

> And as Ron has already said, it wouldn't be able to be heard anyway because his headphones are connected to the hardware mixer, not Mixxx's Headphones output.

I think he schould be able to here the Recording/Broadcasting PFL stream in the same way on his external Mixxer like he can listen to the Library Preview Deck. The Headphone channel can be routed to the Mixxer in addition to the Master Mix.

Revision history for this message
Be (be.ing) wrote :

> When hearing the sound you can Identify a clipped signal in an early stage, where the signal level in Mixxx is still green for example.

If the signal is clipping and Mixxx's meters do not show it, then the meters are broken.

> The Headphone channel can be routed to the Mixxer in addition to the Master Mix.

Huh? Why would someone use a valuable pair of sound card outputs and an input channel on their mixer for this instead of routing a deck to the mixer? The mixer already has its own PFL bus. Using two different PFL buses, one in software and one in hardware would be confusing.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

> If the signal is clipping and Mixxx's meters do not show it, then the meters are broken.

Not necessarily. The Signal can clip inside the external mixer. Than it can be revelled to lets say -6 dB of full analogue scale and passed though the sound card to mixxx. Mixxx VU meter will see the clipping signal but levelled to the green region. No clipping light is lit.

Actually the mixxx VU meter cannot even distinguish a clipping signal from a signal which is properly levelled to ADC full scale both have samples with value 65535.

> Huh? Why would someone use a valuable pair of sound card outputs and an input channel on their mixer for this instead of routing a deck to the mixer?

Because in this case he can PFL samplers and use the library preview deck. (.. and the new Recording/Broadcasting PLF)

> The mixer already has its own PFL bus. Using two different PFL buses, one in software and one in hardware would be confusing.

In case of Mixxx PLF, the hardware mixer need to enable PLF on the Mixxx headphone channel. This is IMHO not too confusing to be a valid alternative.

Revision history for this message
Be (be.ing) wrote :

> Actually the mixxx VU meter cannot even distinguish a clipping signal from a signal which is properly levelled to ADC full scale both have samples with value 65535.

There are ways to detect clipping in the digital signal, but they are imperfect and computationally expensive. https://dsp.stackexchange.com/questions/65/what-are-good-ways-to-detect-signal-clipping-in-a-recording
Even if Mixxx does not attempt to detect a clipped input signal, a meter in Mixxx that is near the top could give a hint to check the sound card's input meter. If Mixxx does not attempt to detect a clipped input signal, then the input meter tooltips should explain this and so should the manual.

RJ Skerry-Ryan (rryan)
Changed in mixxx:
importance: Undecided → Wishlist
status: New → Confirmed
summary: - meter for Record/Broadcast input
+ meter or clipping warning for Record/Broadcast input
tags: added: broadcast
Revision history for this message
Inanna Moon (inannamoon) wrote :

> Why would someone use a valuable pair of sound card outputs and an input channel on their mixer for this instead of routing a deck to the mixer? The mixer already has its own PFL bus. Using two different PFL buses, one in software and one in hardware would be confusing.

My Tascam 208i has 8 outputs (4 output pairs) to go with the Mixxx outputs I use (Decks 1 and 2, samplers on Center, Preview Deck on headphones). My (3rd hand) Mackie mixer has even more inputs. So, routing Mixxx's headphone output to an input pair on the mixer is no problem. And it means I can listen to the Preview Deck (or other Mixxx PFL) without extra equipment.

But, what I can't currently do is check what Mixxx is receiving through its Broadcast input without re-assigning Mixxx's output channels. A PFL on the Broadcast input would save me from having to do this.

Revision history for this message
Be (be.ing) wrote :

I understand your use case, but that is a very esoteric setup. I am concerned that if we added such a feature to the UI it would confuse far more people than would have any use for it.

Revision history for this message
Be (be.ing) wrote :

I do think a meter for the record/broadcast input would be helpful though.

Revision history for this message
Inanna Moon (inannamoon) wrote :

> I do think a meter for the record/broadcast input would be helpful though.

Significantly less helpful than a PFL.

How helpful did Mixxx devs think a Broadcast input would be? Or the Booth output?

I have experence as both a DJ and an engineer at a college radio station. I've trained techno-phobic, new DJs to use the audio console. I even helped install and customize a new (to us) audio console. Yes, some of the other DJs had "crazy" feature requests, but some of those turned out to be useful to all of us.

I like Mixxx because with it, my laptop can be used as a portable radio station. My main setup is at home. Going mobile, I take only the equipment I think I'll need.

Revision history for this message
ronso0 (ronso0) wrote :

I think the Broadcast Pfl is a valid request. Though, the name PREflight implies there's a volume control or a mute switch for the broadcast signal, before it's sent to outputs, which there isn't.

What @be is worried about (I think) is where to add that Pfl control. Currently we only have a Broadcast button in our skin toolbars which should not be crammed with additional controls. An optional Broadcast rack would relax the situation: regular users will not be bothered by this in the GUI, and we could add status indicators for multiple broadcast connections, add the Pfl button there and what not.

Revision history for this message
Be (be.ing) wrote :

I do think adding a broadcasting section to skins could be helpful.

Revision history for this message
Inanna Moon (inannamoon) wrote :

At least in the Tango skin, the tool bar, even at minimum window width, has plenty of room to add a PFL button between the Broadcast button and the clock. (I like how compact Tango is and the amount of functionality it manages to "cram".)

Though, if a Broadcast "rack" (or section) were added, I'd want a status indicator, in the tool bar, that works the same way as the current indicator works (gray for off, yellow for connecting, green for "on air" and purple (or red) for a problem) - perhaps the button itself, like how the current Broadcast button works.

tags: added: hackathon
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/9070

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.