Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tests for invalid phonemes fallbacks fail on latest pocketsphinx #2574

Open
PureTryOut opened this issue May 6, 2020 · 20 comments
Open

Tests for invalid phonemes fallbacks fail on latest pocketsphinx #2574

PureTryOut opened this issue May 6, 2020 · 20 comments

Comments

@PureTryOut
Copy link
Contributor

I'm running the tests on Alpine Linux using system packages and Python 3.8.

I currently have all tests succeeding except for PocketSphinxTest.testInvalid and LocalRecognizerInitTest.testListenerConfig. It seems the fallback for invalid phonemes isn't working.

============================================================= FAILURES ==============================================================
___________________________________________________ PocketSphinxTest.testInvalid ____________________________________________________

self = <test.unittests.client.test_hotword_factory.PocketSphinxTest testMethod=testInvalid>

    def testInvalid(self):
        config = {
            'hey Zeds': {
                'module': 'pocketsphinx',
                'phonemes': 'ZZZZZZZZZ',
                'threshold': 1e-90
            }
        }
        p = HotWordFactory.create_hotword('hey Zeds', config)
>       self.assertEqual(p.phonemes, 'HH EY . M AY K R AO F T')
E       AssertionError: 'ZZZZZZZZZ' != 'HH EY . M AY K R AO F T'
E       - ZZZZZZZZZ
E       + HH EY . M AY K R AO F T

test/unittests/client/test_hotword_factory.py:43: AssertionError
------------------------------------------------------- Captured stdout call --------------------------------------------------------
2020-05-06 14:10:53.204 | INFO     |  7488 | mycroft.client.speech.hotword_factory:load_module:386 | Loading "hey Zeds" wake word via pocketsphinx
____________________________________________ LocalRecognizerInitTest.testListenerConfig _____________________________________________

self = <test.unittests.client.test_local_recognizer.LocalRecognizerInitTest testMethod=testListenerConfig>
mock_config_get = <MagicMock name='get' id='139759354767968'>

    @patch.object(Configuration, 'get')
    def testListenerConfig(self, mock_config_get):
        """Ensure that the fallback method collecting phonemes etc.
        from the listener config works.
        """
        test_config = base_config()
        mock_config_get.return_value = test_config
    
        # Test "Hey Mycroft"
        rl = RecognizerLoop()
        self.assertEqual(rl.wakeword_recognizer.key_phrase, "hey mycroft")
    
        # Test "Hey Victoria"
        test_config['listener']['wake_word'] = 'hey victoria'
        test_config['listener']['phonemes'] = 'HH EY . V IH K T AO R IY AH'
        test_config['listener']['threshold'] = 1e-90
        rl = RecognizerLoop()
        self.assertEqual(rl.wakeword_recognizer.key_phrase, "hey victoria")
    
        # Test Invalid"
        test_config['listener']['wake_word'] = 'hey victoria'
        test_config['listener']['phonemes'] = 'ZZZZZZZZZZZZ'
        rl = RecognizerLoop()
>       self.assertEqual(rl.wakeword_recognizer.key_phrase, "hey mycroft")
E       AssertionError: 'hey victoria' != 'hey mycroft'
E       - hey victoria
E       + hey mycroft

test/unittests/client/test_local_recognizer.py:76: AssertionError
@forslund
Copy link
Collaborator

forslund commented May 6, 2020

Python 3.8 passes all tests on Travis, gonna test it locally as well to confirm.

Do you know which version of pocketsphinx and python-pocketsphinx is being used?

@PureTryOut
Copy link
Contributor Author

0.1.15, which is probably the problem here, being 15 point releases further 😉

@forslund
Copy link
Collaborator

forslund commented May 6, 2020

Did a quick test and upgraded pocketsphinx resulting in me getting the exact same issue so definitely the issue.

@PureTryOut PureTryOut changed the title Tests for invalid phonemes fallbacks fail Tests for invalid phonemes fallbacks fail on latest pocketsphinx May 6, 2020
@PureTryOut
Copy link
Contributor Author

Cool, at least I now know where to look. I'll investigate!

To be honest I'm amazed this is the only problem that comes with the newer versions, seeing how strict Mycroft normally keeps their dependencies

@forslund
Copy link
Collaborator

forslund commented May 6, 2020

Lol yeah, me too! We've had our fair share of breakage though when doing updates (py2 to 3 was rough, and upgrading from the arcane tornado version to the newer one was quite annoying)

@PureTryOut
Copy link
Contributor Author

PureTryOut commented May 7, 2020

Interesting enough release 0.1.5 through 0.1.15 was done in a space of 3 days, and the tests still break on 0.1.3 which was the first release available on PyPi after 1.0.

0.1.0 is actually from June 2016, so I guess the dep never has been upgraded in mycroft-core since the public release? At least now I know the breakage is somewhere between the 4th of June 2016 and the 12th of September 2016 (between 0.1.0 and 0.1.3).

@PureTryOut
Copy link
Contributor Author

PureTryOut commented May 7, 2020

Hmpf, the problem isn't in pocketsphinx-python itself, it's in the submodule pocketsphinx it uses. If I use pocketsphinx-python 0.1.0 but with newer submodules, the tests break in the same way. But if I use it with the submodules that come with that release, it works fine. I guess that is the issue of using libraries without releases...

In fact, the breakage is between https://github.com/cmusphinx/pocketsphinx/commits/ec89abd9d2e976019338ecae7d6cafeecdb95eb2 and https://github.com/cmusphinx/pocketsphinx/commits/a60982363101704eca342e7e0920754090cd49b1

pocketsphinx-python 0.1.15 with the submodules from 0.1.0 actually makes these tests succeed!

@PureTryOut
Copy link
Contributor Author

PureTryOut commented May 7, 2020

Gotcha, cmusphinx/pocketsphinx@08e367e is the commit that broke it. I'm not sure how this breaks things, but maybe it's obvious to someone?

@PureTryOut
Copy link
Contributor Author

@forslund
Copy link
Collaborator

forslund commented May 7, 2020

Nice find, so instead of passing a keyphrase we need to write the keyphrase and threshold to a tmp file and pass that in? Or is it somehow similar to the -dict file that's used to pass in phonemes and word mappings (I think it is atleast)?

@PureTryOut
Copy link
Contributor Author

Well the test file used by pocketsphinx contains just a few things:

anything /1e-10/
something
bad line / here
just bad line /
forward

non_existign_word

So it seems like it can be a tmp file, but I'm not sure, I don't know pocketsphinx 😂

@forslund
Copy link
Collaborator

forslund commented May 7, 2020

I did a test changing the -keyphrase to -kws and a similar file but gets the same issue. I wonder if there's a way to explicitly verify the phonemes validity other than expecting an error from the Decoder creation. But I may also just doing something wrong

@forslund
Copy link
Collaborator

forslund commented May 7, 2020

Hmm https://cmusphinx.github.io/wiki/faq/ suggests that -keyphrase still is valid...

@PureTryOut
Copy link
Contributor Author

Hmm maybe. I guess -keyphrase is always a single phrase, where -kws may contain multiple phrases.

Then it probably goes wrong in verifying the keyphrase it's passed, since that logic has changed.

@forslund
Copy link
Collaborator

forslund commented May 7, 2020

If you got other things to dig into I can try to spend some time finding some solution to this tomorrow or so.

@PureTryOut
Copy link
Contributor Author

I have tons of things to do haha. Main problem here is that this is a bit out of my league, so I would love it if you could take a look at it.

@PureTryOut
Copy link
Contributor Author

@forslund did you have any luck with this by any chance?

@forslund
Copy link
Collaborator

I haven't gotten all the way through it. I may have a workaround half-done (if it works)

@PureTryOut
Copy link
Contributor Author

@forslund how is your workaround going?

@forslund
Copy link
Collaborator

Well my first attemt didn't work at all. Sort of forgot about it recently, sorry. Gonna give it some extra attention...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants